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Обеспечение безопасности операционных 
систем семейства І_іпих 

1.1. Понятие защищённой (доверенной) операционной системы 

Существуют два основных подхода к трактовке понятия защищённой 
автоматизированной системы (АС), применимых к операционным системам (ОС). Первый 
подход подразумевает, что защищённость ОС обеспечивается при реализации некоторых 
заданных изначально (например, в соответствующих стандартах или руководящих 
документах [9, 61, 83]) требований по безопасности, включая наличие некоторого набора 
механизмов защиты, проверку отсутствия предопределённого перечня уязвимостей и т. п. 
При втором подходе рассматривается возможность использования ОС в составе АС, которые 
считаются их владельцами (пользователями) критическими, в связи с чем в ОС должен 
обеспечиваться комплекс средств защиты информации (СЗИ), адекватный угрозам 
безопасности именно этих систем. На первый взгляд, эти два подхода не противоречат друг 
другу, так как вряд ли в критических АС будут применяться решения, не реализующие хотя 
бы минимальные требования по безопасности. Вместе с тем ОС при выполнении всех 
требований по безопасности может быть контролируема извне, например её разработчиком. 
В указанных условиях второй подход подразумевает, что под защищёнными 
подразумеваются решения, которые в англоязычной литературе обозначаются термином 
Ігизіесі, или, в отечественной интерпретации —доверенные. 

Таким образом, защищённой (доверенной) целесообразно считать ОС, которая не 
только реализует заданные априорно требования безопасности, но и адекватна угрозам 
безопасности, специфичным для отечественных АС, в том числе для которой отсутствует 
возможность несанкционированного влияния на её работу извне, при этом владелец 
(пользователь) защищённой ОС должен иметь однозначное представление об алгоритме 
функционирования её защитных механизмов во всех режимах работы 

Это требование становится все более актуальным в последние годы. Автоматическое 
обновление, автоматическое оповещение разработчиков о программных ошибках, 
разнообразные онлайн-сервисы существенно повышают потребительские качества 
прикладного и системного программного обеспечения ОС, но, с другой стороны, создают все 
больше возможностей для производителей ПО, в том числе ОС, контролировать действия 
пользователей [98, 126]. Для целого ряда применений защищённых ОС вопрос доверия к её 
разработчику оказывается более значимым, чем вопрос об объёме и качестве реализации в 
данной ОС стандартных механизмов обеспечения безопасности. 

Именно этими соображениями можно объяснить рост интереса к отечественным 
защищённым ОС, отмечающийся в последнее время в Российской Федерации со стороны 
органов государственной власти и предприятий промышленности. Дополнительным 



стимулом по данному направлению стало принятое Правительством Российской Федерации 
решение об установлении запрета на допуск ПО, происходящего из иностранных государств, 
для целей осуществления закупок для обеспечения государственных и муниципальных нужд 
[50], планируемое «законодательное закрепление норм, обеспечивающих преференции для 
компьютерного, серверного и телекоммуникационного оборудования и ПО отечественного 
производства при осуществлении закупок для государственных и муниципальных нужд, а 
также при предоставлении различных форм государственной поддержки» [88]. 
Высказываются прогнозы, что в случае утверждения и принятия Программы развития 
российского сегмента сети Интернет «к 2025 году все государственные учреждения и 
стратегические предприятия будут оснащены компьютерами на российской элементной базе 
с отечественной операционной системой на борту» [62]. 

В современных условиях перспективная отечественная защищённая ОС должна 
отвечать следующим требованиям: 

• соответствовать требованиям обеспечения технологической независимости 
(импортозамещения) Российской Федерации в важнейших областях информатизации, 
телекоммуникации и связи; 

• быть пригодной к функционированию в компьютерных сетях, как изолированных, так 
и подключённых к сети Интернет (или иным телекоммуникационным сетям), в том числе 
ориентированных на обработку информации, отнесённой к государственной тайне, или 
персональных данных; 

• реализовывать современные механизмы обеспечения информационной 
безопасности, учитывающие возможность обработки в данной ОС информации, отнесённой 
к государственной тайне, как с точки зрения удовлетворения формальных требований 
соответствующих нормативных документов и стандартов, так и с точки зрения обеспечения 
реальной защиты от актуальных угроз безопасности. 

Разработчик такой ОС должен обладать развитой инфраструктурой разработки и 
сопровождения её прикладного и системного ПО. Должны быть реализованы механизмы, 
обеспечивающие доверие к разработчику ОС, возможность научного обоснования (хотя бы 
неформального) безопасности реализуемых в ней программно-технических решений. 

1.2. Обзор защищённых операционных систем 
семейства Ыпих 

Принято считать, что ОС Ипих (точнее, ОЛ/Ш-і/л/х) [41] была создана в 1991 г. 21- 
летним финским программистом Линусом Торвальдсом. Фактически он переписал с нуля 
ядро ОС Міпіх, ничем не примечательного «клона» ОС семейства ё/Д//Х.Долгое время 
единственным преимуществом ОС Ипих по сравнению с другими ё//Ѵ/Х-системами была 



лицензионная чистота программного кода ОС Ипих, позволяющая разворачивать на её базе 
самые разнообразные информационные системы, не беспокоясь о потенциальных 
сложностях с лицензиями. Примерно до 2000 г. ОС Ипих ничем не выделялась среди других 
ОС семейства 0//Ѵ/Х, заметно уступая многим из них по производительности и надёжности. 

Долгое время открытость программного кода ОС Ипих оставалась единственным 
фактором, делавшим данную ОС привлекательной для разработчиков прикладного ПО. 
Однако со временем разнообразие ПО, адаптированного под ОС Ипих, достигло некоторой 
«критической массы», и ситуация изменилась. По мере того как ОС Ипих становилась де- 
факто стандартом в мире ОС семейства Т/Л//Х ,все больше программистов разрабатывали 
прикладное и системное ПО, предназначенное для работы под управлением ОС Ипих, а 
компоненты ОС подвергались все более тщательному тестированию и оптимизации. Начиная 
с какого-то момента, нарастание популяр¬ 
ности ОС Ипих стало самоподдерживающимся процессом, и в настоящее время эти ОС 
составляют более 90% ОС семействаё/МХ/./шх-системы лидируют на рынках смартфонов, 
самых мощных суперкомпьютеров, занимают примерно половину рынка встраиваемых 
систем, имеют значительную долю рынка нетбуков [40]. 

При сравнении ОС семейства Ипих с более популярными ОС семейств МісгозоП 
ѴѴІпсІоѵѵз или Мае 05 бросается в глаза характерная особенность Ипих- систем — они 
первоначально в большей мере были ориентированы на профессиональных 
высококвалифицированных пользователей. Заметная доля действий, необходимых для 
настройки системы, а в некоторых случаях и для приведения её в работоспособное 
состояние, выполняется путём ручного редактирования конфигурационных файлов, 
редактирования или написания с нуля различных скриптов и т.д. По этой причине ранние 
версии ОС семейства Ипих были практически недоступны массовому пользователю, сейчас 
этот недостаток в основном преодолён современные версии ОС семейства Ипих требуют 
лишь минимального обучения. Часто пользователи даже не знают, что работают именно с 
ОС этого семейства, так, например, популярная мобильная ОС Апдгоід фактически 
представляет собой пакет системного ПО, развёрнутого на платформе ОС семейства Ипих. 

Среди многих пользователей ОС семейства Ипих бытует мнение , что данная ОС 
отличатся необычно мощно и практически мощной и практически неуязвимой подсистемой 
защиты. В качестве аргументов в поддержку этой точки зрения обычно приводят наличие в 
них базовых механизмов дискреционного управления доступом, аутентификации и аудита, 
которые аналогичны или даже уступают соответствующим механизмам других ОС. Также 
встречается аргументация, что практически полное отсутствие вредоносного ПО для ОС 
семейства Ипих является следствием того, что эта система значительно лучше защищена 
против вирусных атак, чем, например, ОС семейства МісгозоП ѴѴІпсІоѵѵз. Это совершенно 



неверно. Действительно, вирусы для ОС семейства Ипих практически не встречаются «в 
дикой природе» хакерского сообщества, но это обусловлено отнюдь не высокой 
защищённостью этих ОС. Программисту средней квалификации несложно убедиться, что 
написание компьютерного вируса или иной вредоносной программы для ОС семейства Ипих 
ничуть не сложнее (за исключением некоторых узких классов вредоносных программ), чем 
написание аналогичной программы, например, для ОС семейства МісгозоП ѴѴІпсІоѵѵз . 
Незначительное число Ипих- вирусов объясняется в основном тем, что разработчики 
вредоносного ПО предпочитают ориентироваться на более популярные программные 
платформы, для которых нелегальная деятельность киберпреступников приносит 
наибольший доход. . Вазовые средства безопасности ОС семейства Ипих унаследованы от 
ранних версий ОС семейства ^NIX, разрабатывавшихся в начале 70-х голов прошлого 
столетия. Исходя из требований обратной совместимости со старыми версиями, ОС 
семейства Ипих продолжают поддерживать целый ряд устаревших защитных механизмов и 
концепций. В частности, в подсистемах защиты большинства этих ОС присутствуют 
следующие «анахронизмы»: 

• все объекты (сущности) доступа должны интерпретироваться как файловые объекты, 
атрибуты защиты других типов объектов не могут корректно описываться штатными 
средствами ОС; 

• не поддерживаются глобальные уникальные идентификаторы учётных записей 
пользователей, все идентификаторы пользователей и групп уникальны только в пределах 
одного экземпляра ОС; 

• набор прав доступа субъектов (процессов) к сущностям (файлам, каталогам) сильно 
ограничен, поддерживаются только три права доступа: чтение, запись и выполнение, а также 
задаётся владелец каждой сущности; 

• полномочия суперпользователя тооф практически неограничены; 

• отсутствуют механизмы автоматического назначения атрибутов защиты вновь 
создаваемым сущностям на основе атрибутов защиты контейнеров (каталогов), где эти 
сущности создаются; 

• для динамического изменения полномочий субъектов доступа 

применяется неудобный и потенциально опасный механизм 5Ш0/50Ю\ 

• не поддерживаются механизмы олицетворения субъектов доступа, осуществляющих 
клиентский доступ к процессу-серверу; 

• поддерживаемые средства минимизации полномочий пользователей крайне 
примитивны; 

• не поддерживается мандатный контроль целостности; 

• не поддерживается изолированная программная среда, даже частично. 



Отдельно стоит отметить проблемы безопасности графического интерфейса X 
ѴѴІпсіоѵѵз Зузіет, используемого в современных версиях ОС семейства Ипих для 
взаимодействия с процессами пользователей. Энтузиасты ОС семейства Ипих любят 
критиковать ОС семейства МісгозоН ѴѴІпсіоѵѵз за недостаточную защищённость её 
графической подсистемы, например: «В ОС МісгозоН ѴѴІпсіоѵѵз Л/Т любой процесс независимо 
от уровня своих привилегий может послать сообщение окну другого процесса (в том числе и 
более привилегированного!), причём нет никакой возможности установить от отправителя 
сообщения!... Находим окно какого-нибудь привилегированного приложения (а такая 
возможность у нас есть), получаем дескриптор интересующего нас элемента управления 
(кнопки, пункта меню, строки редактирования) и... эмулируем ввод пользователя!!! 
Привилегированный процесс все сделает за нас, так ничего при этом и не заподозрив!» [28]. 

На самом деле указанная проблема характерна не только для ОС семейства МісгозоН 
ѴѴІпсіоѵѵз . Ещё в 1994 г. Р. Браатен в нашумевшем в своё время сообщении в конференции 
сотр.зесигііу.ипіх [106] сформулировал угрозу похищения графическим приложением X 
ѴѴІпсіоѵѵз Зузіет учет конфиденциальной информации, адресованной другому графическому 
приложению. В ОС семейства МісгозоН ѴѴІпсіоѵѵз , начиная с ОС МісгозоН Ѵізіа, введён 
мандатный контроль целостности графических сущностей, значительно повысивший 
защищённость графической подсистемы, однако в X ѴѴІпсіоѵѵз Зузіет ничего подобного не 
произошло [60]. 

Среди администраторов безопасности ОС семейства Ипих распространено мнение, 
что для её превращения в высокозащищённую ОС достаточно установить пакет Зесигііу 
Епііапсесі ипих{ЗЕИпих) специально разработанный для этой цели в АНБ США [236]. Данный 
пакет широко и успешно применяется для реализации замкнутой программной среды, однако 
попытки его применить для реализации более сложных моделей управления доступом, как 
правило, кончаются неудачей, так как требуют существенных усилий по разработке 
соответствующих политик. На рис. 1.1 показан типичный вид рабочего стола после включения 
М/.$-политики[17,,103] ЗЕНпих в Еесіога Ипих. 

Попытки построить на базе ОС семейства Ипих защищенную ОС неоднократно 
предпринимались как в России, так и за рубежом. Исторически можно считать, что первым 
проектом в данном направлении является ОС Ипих-Мапсігаке Низзіап Есііііоп 
.разрабатывавшаяся группой энтузиастов в 1999-2000 гг. и в дальнейшем «выросшая» в 
проект ОС А/.Г Ипих, поддерживаемый компанией «Альт Линукс». Начиная с 2005 г., 
дистрибутив ОС А/.Г Ипих является полностью самостоятельным [97]. Подсистема 
безопасности ОС А/.Г Ипих несколько интересных нововведений (раздельное хранение 
аутентификационных данных разных пользователелей, минимизация количества ЗІІЮ. и 
ЗСЮ-программ), которые однако, не оказывали существенного влияния на общую 



защищенность ОС. В настоящее время этот проект реализуется ООО «Базальт СПО», 
выпускающей ОС Альт, некоторые дистрибутивы которой реализуют мандатное управление 
доступом [1] на основе пакета 



Рисунок 1. Пример результата включения МІ-8-политики ЗЕИпих в Ресіога Ипих 


ЗЕИпих [136]. При этом ОС Альт СП 8 является несомненно лучшей реализацией 
пакета ЗЕИпих среди всех известных авторам ОС. Тем не менее экспериментально показано, 
что эта ОС имеет ряд потенциальных уязвимостей в подсистеме мандатного управления 
доступом, связанные с реализацией информационных потоков по времени: возможна утечка 
конфиденциальной информации через устройства /сіеѵ/різ/*, через системные журналы, через 
уязвимости графической подсистемы. 

Какое-то время самой защищённой российской ОС семейства Ипих являлась 
Мобильная система Вооружённых Сил (МСВС),разработанная по заказу Минобороны России 
Всероссийским научно-исследовательским институтом автоматизации управления в 
непромышленной сфере (ВНИИНС) на основе ОС РесІ Наі Епіегргізе Ипих[ 6]. ОС МСВС была 
принята на снабжение вооружённых сил в 2002 г. На протяжении многих лет она широко 
применялась в самых различных компьютерных системах военного и двойного назначения, 
существуют её настольные и серверные версии, предназначенные для функционирования на 
обычных бытовых компьютерах. 

Последняя достоверно существующая (о более новых версиях авторами информации не 
найдено) версия МСВС 5.0, сертифицированная в 2011 г, содержит ядро Ипих версии 2.6.32 
и дІіЬс версии 2.5 сборки 2006 г. Утверждается [78], что установка дополнительного ПО в 














данную ОС серьёзно затруднена. Осенью 2017 г. появились сведения, что ОС МСВС 
работает на отечественной аппаратурной платформе «Эльбрус». 

Около 2003 г. началась разработка северокорейской ііпих- системы Яес/ $/аг[130]. В 
2013 г. экземпляр данной ОС попал в руки экспертов германской компании ЕЛ/Я 1/1/. 
Утверждается, что «правительству КНДР удалось создать на базе ііпих полноценную 
ОС,большую часть кода которой действительно контролирует правительство». Яес/ Зіаг 
обладает собственной системой шифрования файлов, разработанной корейскими 
программистами, а также функциями защиты собственной целостности. Система Яес/ Зіаг 
при попадании файлов на жёсткий диск или при подключении ІІЗВ накопителя к компьютеру 
добавляет к ним сервисную информацию, позволяющую отслеживать источник файла и его 
движение от пользователя к пользователю. Таким образом, власти могут установить 
распространителя запрещённой на территории страны информации. 

В 2006 г. на Украине компанией «Майлинукс» была разработана первая украинская ОС, 
названная туііпих [5]. Весной 2014 г. был анонсирован [84] проект другой украинской ОС, 
которая будет построена на основе ОС семейства ііпих , откуда «будут вырезаны продукты 
и приложения, которые смогут повлиять на её безопасность». Предполагалось, что к концу 
лета того же года проект будет представлен на рассмотрение Совета национальной 
безопасности и обороны Украины, однако никаких сообщений, что это действительно 
произошло, в доступных источниках не обнаруживается. 

В 2006 г. в Китае начались поставки в военные и государственные учреждения ОС 
Куііп, разработанной китайским Национальным университетом оборонных технологий на 
базе ОС ВгееВЗО[ 118]. Название ОС означает мифическое животное, часто упоминающееся 
в китайском фольклоре наряду с драконом и фениксом. Дистрибутив ОС Куііп некоторое 
время был доступен для скачивания. По мнению экспертов [119] данная ОС не содержит 
каких-либо выдающихся защитных механизмов, никто не упоминает о поддержке в ней 
мандатного управления доступом, мандатного контроля целостности, изолированной 
программной среды и т. п. В 2013 г.официально стартовал проект ОС ІІЬипІи Куііп, по всей 
видимости, не имеющий ничего общего с ОС Куііп, кроме названия. ОС ІІЬипІи Куііп 
представляет собой версию ОС ІІЬипІи ііпих с полнофункциональной поддержкой китайского 
языка и несколькими предустановленными приложениями, специфичными для Китая (лунный 
календарь, упрощённый:лоступ к китайским социальным сетям, поставщикам китайской 
музыки и т, п.). Есть сведения [144], что обычный дистрибутив ІІЬипІи легко превращается в 
ОС ІІЬипІи Куііп в результате установки нескольких дополнительных пакетов ПО. Нет никаких 
сведений, что подсистема безопасности данной ОС чем-либо отличается от подсистемы 
безопасности ОС ІІЬипІи ііпих. При этом ОС ІІЬипІи Куііп эксплуатируется не только в Китае. 



Около 15 тыс. компьютеров с предустановленной данной ОС были поставлены на Украину в 
качестве гуманитарной помощи [120]. 

Семейство отечественных ОС «РОСА» производится с 2009 г, группой компаний 
«РОСА» изначально на основе ОС Мапдгіѵа Ипих [132]. Семейство ОС «РОСА» включает в 
себя сертифицированные защищённые ОС «РОСА Хром» и «РОСА Никель», в которых 
заявлена поддержка мандатного управления доступом [64,65], а также «РОСА Кобальт» и 
несколько свободно распространяе-мых дистрибутивов, потребительские качества которых 
оцениваются пользователями довольно высоко [51]. Весной 2015 г, «НТЦ ИТ РОСА» вошла 
в число пяти российских компаний, подавших заявку на государственную поддержку 
отечественных программных продуктов [32]. В 2018 г. появились сведения о разработке 
дистрибутива ПОЗА Епіегргізе Зегѵег, основанного на Пед Наі Епіегргізе Ипих[ 31]. Сведений 
о существенных научно обоснованных технических решениях в области информационной 
безопасности, заложенных в 

основу разработки данной ОС, обнаружить не удалось. 

В 2010 г. знаменитая польская исследовательница безопасности ОС Йоанна Рутковска 
объявила, что ведёт разработку защищённой ОС ОиЬез, основанной на ОС Еегіога Ипих 
[129]. Дополнительные средства защиты данной ОС основаны на инкапсуляции прикладных 
и системных программ в отдельные виртуальные машины, взаимодействие которых 
реализуется посредством гипервизора Хеп. Передача данных между виртуальными 
машинами осуществляется на основе общесистемной политики безопасности, потенциально 
способной поддерживать мандатное управление доступом, мандатный контроль 
целостности, изолированную программную среду и т.п. Для пользователя наличие этой 
политики становится заметным только в том случае, если он попытается её нарушить, иначе 
работа пользователя выполняется как в обычной ОС Еедога Ипих. Окна программ, 
принадлежащих к разным виртуальным машинам, выполняются на 

общем рабочем столе, как при включённом зеатіезз тогіе в ПО ѴігіиаІ Вох (в русскоязычной 
локализации этот режим называется «Режим интеграции дисплея». 

Позже похожая идея была реализована отечественной компанией «НеоБИТ», 
изготовившей гибридную ОС Ипих оѵег ЕеЬоз, в которой прикладные программы 
выполняются в виртуальных машинах ОС Ипих, выступающих, в свою очередь, в роли 
прикладных программ ОС «Фебос» — собственной разработки «НеоБИТ»,не имеющей 
отношения к семейству ОС Ипих |8]. Фактически, ОС «Фебос», насколько можно судить по 
доступным описаниям, не содержит в себе ничего, кроме микроядра, гипервизора и монитора 
безопасности, все прикладные интерфейсы вынесены в виртуальные машины ОС Ипих. 

ОС «Заря» разработана АО «Центральный научно-исследовательский институт 
экономики информатики и систем управления» (ЦНИИ ЭИСУ) [89] по заказу Минобороны 



России в 2013 г. [92]. Данная ОС основана на ОС СепЮз Ипих и ОС Яес/ Наі Епіегргізе Ипих 
, доступные в сети Интернет схемы её архитектуры не содержат никаких уникальных 
особенностей, существенно отличающих её от других ОС семейства Ипих. Некоторые 
источники позиционируют ОС «Заря» как следующее поколение ОС МСВС [82]. 
Утверждается, что ОС «Заря» совместима с пакетами ПО ИЬге ОНісе , ОІМР и СЬютіит , 
существуют версии ОС для настольных, серверных и встраиваемых систем, версия «Заря- 
ЦОД» для построения центров обработки данных, «Заря РВ» — дистрибутив, 
предназначенный для построения ОС реального времени «для встраиваемых систем, 
работающих без участия человека, которые должны обрабатывать информацию в режиме 
реального времени» [48], а также универсальная интеграционная шина (УИН!) «Заря», 
предназначенная для построения систем информационного обмена в задачах АСУ [47]. 
Никаких демонстрационных версий ОС «Заря» не обнаружено, а доступные в сети Интернет 
снимки экранов неинформативны. В 2015 г ЦНИИ ЭИСУ, кроме того, объявило о создании на 
базе ядра ОС тих мобильной ОС «РоМОС», которая «подразумевает отсутствие утечки 
информации, исключает различные закладки, делает невозможной установку шпионского 
ПО, прослушку» [67]. 

Обоснований этих утверждений в доступных источниках не обнаруживается. В сентябре 2015 
г. ЦНИИ ЭИСУ, объявило о готовности серийному производству новой ОС «Рассвет», 
представляющей собой развитие серии специализированных ОС «Заря» [3]. 

В 2013-2014 гг. компанией «Ред Софт» по заказу ФССП Россий разработана ОС 
«ГосЛинукс», также основанная на ОС СепЮЗ которая позиционируется как защищённая ОС 
с функциями, позволяющими «приставу обрабатывать персональные данные должников и 
взыскателей без дополнительных средств защиты информации, а также применять 
электронную подпись для издания документов в электронном виде» [30]. На официальном 
сайте ФСПП России 

утверждается, что «основные доработки, выполненные подрядчиком, касались 
криптографической подсистемы и предконфитурации встроенных средств защиты 
информации» [46]. Позже той же компанией была разработана ОС «Ред ОС», которая, как 
утверждает разработчик, «имеет в своём составе слециализированную подсистему 
распределённого аудита, которая позволяет отслеживать критичные события безопасности 
в корпоративной сети и предоставляет ІТ-администратору необходимые инструменты для 
оперативного реагирования на инциденты ИБ» [125]. О иных функциях безопасности, 
выходящих за рамки типичных для других ОС семейства Ипих ,ничего не сообщается. 

Не позднее 2014 г. корпорацией «Росатом» создана так называемая «Защищённая 
операционная система для суперЭВМ» (ЗОС), основанная на программной платформе ОС 
семейства Ипих. Утверждается, что данная ОС сертифицирована ФСТЭК России и «средства 



защиты информации в ЗОС отвечают требованиям технических условий, что позволяет 
применять системное ПО в автоматизированных системах класса защищенности 1В-С» [27]. 
Заявленный перечень реализованных в ЗОС функций безопасности также является 
типичным для Ипих систем. 

ОС «Эльбрус» разработана АО МЦСТ [39] для вычислительных комплексов, 
построенных на основе отечественной аппаратной платформы «Эльбрус». Компания- 
разработчик декларирует возможность применения ОС «Эльбрус» в качестве ОС реального 
времени, утверждает, что <в ядро программной платформы «Эльбрус» встроен комплекс СЗИ 
от несанкционированного доступа, который позволяет использовать ОС для построения 
автоматизированных систем, отвечающих самым высоким требованиям информационной 
безопасности» [125]. Подробности реализации данного комплекса не приводятся. 

Помимо вышеперечисленных ОС, существует целый ряд защищённых ОС семейства 
Ипих, о которых известно либо мало, либо практически ничего, кроме названия. К этой группе 
относятся, в частности, отечественные ОС ЗаііізЬ МоЫІе ОЗ НІІЗ[66], ОС «ОСь» [38], ОС 
«Стрелец», ОС «ОСнова» [37|. 

В целом, несмотря на очевидные недостатки безопасности ОС семейства Ипих , 
широкий спектр не всегда удачных разработок защищённых ОС на их основе, в настоящее 
время ОС этого семейства по прежнему являются почти идеальной платформой для 
создания отечественной защищённой ОС. Используемые в ОС семейства Ипих иногда 
примитивные и устаревшие механизмы защиты позволяют без кардинальной переработки, 
блокирования или учёта их особенностей реализовывать в ОС современные механизмы 
мандатного и ролевого управления доступом, мандатного контроля целостности, и 
добиваться строгого теоретического обоснования безопасности и верификации полученного 
решения. Таким образом, сочетание высокой надёжности, приемлемых потребительских 
качеств, открытого исходного кода и возможности сравнительно лёгкой доработки 
механизмов защиты ОС семейства Ипих позволяют построить на 

их базе высокозащищённую отечественную ОС ценой существенно меньших усилий, чем 
если бы она создавалась с нуля или строилась на других платформах. 

1.3. Архитектура, назначение и области 
применения ОССН 
1.3.1. Назначение ОССН 

Доктрина информационной безопасности Российской Федерации [25] определяет ряд 
стратегических целей в таких областях, как оборона страны, государственная и 
общественная безопасность, экономическая сфера, наука, технологии и образование. В 



общем виде эти цели определяют вектор развития организационных и технологических 
решений, направленных, в том числе на: 

• обеспечение безопасности информации, обрабатываемой в информационных 
системах на территории Российской Федерации; 

• обеспечение устойчивого и бесперебойного функционирования 

информационной инфраструктуры, в первую очередь критической информационной 

инфраструктуры Российской Федерации; 

• повышение безопасности функционирования объектов информационной 
инфраструктуры, в том числе в целях обеспечения устойчивого взаимодействия 
государственных органов; 

• повышение безопасности функционирования образцов вооружения, военной и 
специальной техники и автоматизированных систем управления. 

Эффективное развитие и совершенствование этих решений базируется, в первую 
очередь: 

• на проведении научных исследований и реализации опытных коммерческих 
разработок в целях создания перспективных информационных технологий и средств 
обеспечения информационной безопасности; 

• создании и внедрении информационных технологий, изначально устойчивых к 
различным видам воздействия. 

При этом важнейшим аспектом, актуальным в современных реалиях глобализации 
информационных технологий, связанной с трансграничным характером их внедрения и 
использования, является минимизация, а в перспективе и полная ликвидация зависимости 
отечественных технологических решений от зарубежных информационных технологий и 
средств обеспечения информационной безопасности. Очевидными факторами достижения 
этого являются: 

• создание, развитие и внедрения во все сферы, связанные с применением 
информационных технологий, отечественных разработок; 

• совершенствование методов и способов создания средств и оказания услуг на основе 
информационных технологий с использованием отечественных разработок, 
удовлетворяющих требованиям информационной безопасности; 

• обеспечение конкурентоспособности российских информационных технологий и 
развитие научно-технического потенциала в области обеспечения информационной 
безопасности. 

Таким образом, вопросы ограничения применения в рамках АС (в первую очередь 
функционирующих в интересах органов государственной власти) продукции иностранного 
производства, для которой существуют отечественные аналоги, являются особенно 



актуальными для современных условий. В частности, изменения, внесённые в Федеральные 
законы «Об информации, информационных технологиях и о защите информации» [85] и «О 
контрактной системе в сфере закупок товаров, работ, услуг для обеспечения 
государственных и муниципальных нужд» [86], имеют прямое отношение к курсу на 
импортозамещение, базирующемуся на тенденциях развития рынка российского ПО. 

ОССН в полной мере отражает рассмотренные выше аспекты.Являясь результатом 
планомерного процесса по формированию и совершенствованию системной программной 
платформы для автоматизированных систем в защищённом исполнении (АСЗИ), ОССН 
представляет собой симбиоз решений, базирующихся на концепции свободного ПО, 
органично дополненных совокупностью программных модулей и информационных структур, 
являющихся авторскими разработками АО «НПО РусБИТех». При этом решения, 
заложенные в основу ОССН, представляют собой результат как научных исследований, 
прошедших тщательную научно-техническую верификацию, так и проведения опытно¬ 
конструкторских работ направленных на интеграцию ОССН, как системной платформы, в 
широкий спектр АСЗИ, что подтверждается соответствующими процедурами по 
сертификации СЗИ. 

Актуальная в настоящее время версия 1.6 релиза ОССН «Смоленск», 
ориентированного на применение в классе вычислительных систем, поддерживающих 
процессорную архитектуру х86-64, представляет очередной этап эволюционного развития 
системной программной платформы ОССН. Совершенствование функциональных 
возможностей этой версии основано, как минимум на двух важных тенденциях: 

• использование обратной связи с потребителями, активно эксплуатирующими 
системы в составе широкого спектра АСЗИ,функционирующих на разных вариантах 
платформы х86-64: 

• упреждающий учёт тенденций развития современных АСЗИ,а именно — увеличение 
роли технологий виртуализации платформ в интересах создания гибких, масштабируемых, 
высокопроизводительных и отказоустойчивых инфраструктур, а также решение задач 
кроссплатформенной интеграции и межплатформенной миграции доменных инфраструктур, 
развёртываемых в рамках крупных корпоративных информационных систем. 

При этом, наряду с поддержкой указанных тенденций, важнейшим аспектом развития 
ОССН является совершенствование её компонентов, связанных с функциями защиты 
информации. В этом направлении разработчики ОССН опираются на строгое соответствие 
национальным стандартам в области защиты информации, а также создания и модернизации 
АСЗИ, включая ГОСТ 51583-2014 «Защита информации. Порядок создания 
автоматизированных систем в защищённом исполнении. Общие положения» [12], ГОСТ 
Р58256-2018 «Защита информации. Управление потоками информации в информационной 



системе. Формат классификационных меток» [13], требования системы сертификации СЗИ, 
определённые ФСТЭК России в «Положении о системе сертификации средств защиты 
информации» [49]. 

Версия 1.6 ОССН релиза «Смоленск» имеет следующие сертификаты соответствия 
участников Системы сертификации СЗИ по требованиям безопасности информации (табл. 
1 . 1 ). 

Указанные сертификаты подтверждают возможность использования ОССН в составе 
АСЗИ различных классов защищённости с заданными уровнями защиты от 
несанкционированного доступа к информации (НДС) и наличия недекларируемых 
возможностей (НДВ) 

Таблица 1.1 


Сертификаты ОССН 


Участник системы 

Номер 

Дата получения 

Срок действия 

сертификации 

сертификата 

сертификата 

Сертификата 

Федеральная 

служба 

безопасности 

Российской 

Федерации 

СФ/014-2961 

09.09.2016 

31.08.2021 

Федеральная 
служба по 

2557 

27.01.2012 

27.01.2021 

техническому и 

экспортному 

контролю 

Российской 

Федерации 

1339 

24.09.2010 

17.04.2023 

Министерство 

обороны 

Российской 

Федерации 





в составе компонентов системы, в том числе АСЗИ, обрабатывающих информацию, 
содержащую сведения, составляющие государственную тайну с грифом не выше 
«совершенно секретно». Предельный уровень защиты версии 1.6 релиза ОССН 
сертифицирован для использования в многопользовательских АСЗИ, пользователи которых 
имеют разные полномочия по доступу к обрабатываемой информации (Группа 16), по классу 
3 защиты от НСА и уровню 2 контроля отсутствия НДВ. Кроме того, ОССН версии 1.6 
сертифицирована на соответствие требованиям профиля защиты ОС общего назначения 
(типа «А») второго класса защиты [61]. 

В общем же случае АСЗИ, реализованные с использованием ОССН, могут 
обеспечивать конфиденциальность информации применительно к сведениям 
конфиденциального характера в соответствии с [35], а именно: 




• о фактах, событиях и обстоятельствах частной жизни гражданина, позволяющие 
идентифицировать его личность (персональные данные), за исключением сведений, 
подлежащих распространению в средствах массовой информации в установленных 
федеральными законами случаях, 

• составляющим тайну следствия и судопроизводства, о лицах, в отношении которых в 
соответствии нормативными правовыми актами Российской Федерации принято решение о 
применении мер государственной защиты, а также о мерах государственной зашиты 
указанных лиц; 

• служебным сведениям, доступ к которым ограничен органами государственной 
власти в соответствии с Гражданским кодексом Российской Федерации и Федеральными 
законами (служебная, тайна); 

•связанным с профессиональной деятельностью, доступ к которым ограничен в 
соответствии с Конституцией Российской Федерации и федеральными законами (врачебная, 
нотариальная, адвокатская тайна, тайна переписки, телефонных переговоров, о почтовых 
отправлений, телеграфных или иных сообщений и т.д.); 

• связанным с коммерческой деятельностью, доступ к которым в ограничен в 
соответствии с Гражданским кодексом Российской Федерации и федеральными законами 
(коммерческая тайна); 

• о сущности изобретения, полезной модели или промышленного и образца до 
официальной публикации информации о них; 

• содержащимся в личных делах осуждённых, а также о принудительном исполнении 
судебных актов, актов других органов и должностных лиц. 

Наряду с обеспечением защиты информации, содержащей сведения, составляющие 
государственную тайну, а также информации, содержащей сведения конфиденциального 
характера, ОССН отвечает требованиям Федерального закона «О безопасности критической 
информационной структуры Российской Федерации» [87] в рамках статей 10 и 11 
(предотвращение неправомерного доступа к информации, обрабатываемой значимым 
объектом критической информационной инфраструктуры, уничтожения такой информации, 
её модифицирования, блокирования, копирования, предоставления и распространения, а 
также иных неправомерных действий в отношении такой информации). 

Состав и функциональные возможности компонентов ОССН в полной мере 
соответствуют требованиям, определенным в постановлении Правительства Российской 
Федерации «Об установлении запрета на допуск программного обеспечения, происходящего 
из иностранных государств, для целей осуществления закупок для обеспечения 
государственных и муниципальных нужд [50], разработанного в рамках реализации 
программы Правительства Российской Федерации по импортозамещению. В частности, 



сведения об ОССН включены в единый реестр российских программ для электронных 
вычислительных машин и баз данных [26]. 

В контексте стандартизации и сертификации функциональных решений, заложенных в 
ОССН, важным аспектом её развития является верификация (формальное доказательство) 
непротиворечивости изложенной в главе 2 настоящего учебного пособия мандатной 
сущностно-ролевой ДП-модели безопасности управления доступо информационными 
потоками (МРОСЛ ДП-модели), положенной в основу комплекса СЗИ, и реальной его 
функциональной спецификацией, реализованной в конкретном релизе ОССН. Нормативной 
основой такой верификации являются ГОСТ Р ИСО, МЭК 15408-3-2013 «Методы и средства 
обеспечения безопасности. Критерии оценки безопасности информационных технологий» [9] 
и утверждённые в 2018 г ФСТЭК России «Требования по безопасности информации, 
устанавливающие уровни доверия к средствам технической защиты информации и 
средствам обеспечения безопасности информационных технологий» [83], определяющие 
следующие требования к процессу разработки критически важного с точки зрения защиты 
информации ПО: 

• проведение формального моделирования политики безопасности; 

• верификация непротиворечивости модели политики безопасности с получением 
оценок недостижимости небезопасных состояний системы, в рамках которой эта политика 
безопасности реализуется; 

• разработка формальной функциональной спецификации СЗИ; 

• верификация соответствия между разработанной формальной функциональной 
спецификацией СЗИ и моделью политики безопасности; 

• верификация соответствия между формальной функциональной спецификацией 
СЗИ, проектом ПО СЗИ и реальной реализацией СЗИ. 

В ходе выполнения этих требований разработчики ОССН совместно Институтом 
системного программирования им. В.П. Иванникова Российской академии наук (ИСП РАН) 
решают задачи по созданию и практической апробации методики и инструментальных 
средств верификации МРОСЛ ДП-модели и механизмов СЗИ в ОССН. Для этого ИСП РАН 
разработан комплекс инструментальных средств АзігаѴег Тооізеі для дедуктивной 
верификации СЗИ, реализованных в ОССН [33]. Этот комплекс базируется на проектах 
свободного ПО Носііп Ріаііогт 

(инструментальное средство дедуктивной верификации моделей на формальном 
языке Еѵепі- В), ѴѴМуЗ (платформа дедуктивной верификации Си-программ с использованием 
инструмента Егата-С, основанного на языках спецификаций АС5/. и УѴЬуМЦ [19, 93, 94, 110, 
114]. 
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1.3.2. Архитектура ОССН 

Архитектурной основой ОССН является проект ОеЫап/и пих [34, 41] — ассоциация 
разработчиков свободного ПО, основой которой являются . ОС семейства <ЗN^/^іпиx на базе 
ядра Ыпих КегпеІ [142] . Дистрибутив ОССН включён в список производных 
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Бинарный интерфейс приложений -АВІ (Арріісаііоп Віпагу 
Іпіегіасе) 


Ядро ОІ\ИІ/І_іпих(ипих КегпеІ) драйверы устройств 


Рис. 1.2. Обобщённая архитектура ОС на базе проекта ОІ\ИІ/І_іпих 
дистрибутивов ОеЫап (ветка Низзіап ОеЫап дегіѵаііѵез)[ 109]. В общем случае это 
означает, что сообщество разработчиков ОеЫап признает дистрибутив ОССН как 
удовлетворяющий следующим критериям: 

• разработчики дистрибутива активно взаимодействуют с проектом ОеЬ/'ал; 

• дистрибутив активно сопровождается; 

• в команде разработчиков дистрибутива имеется хотя бы один участник проекта 


ОеЫап: 




• разработчики дистрибутива вступили в программу сбора сведений о производных 
дистрибутивах и добавили файл зоигсез.іізі на страницу сведений о своём производном 
дистрибутиве; 

• производный дистрибутив имеет какую-либо особенность или ориентацию; 

• производный дистрибутив относится к известным (авторитетным) дистрибутивам. 

Таким образом, в целом архитектура ОССН соответствует архитектурным решениям 

ѲЛ/Ш./ШХ (рис. 1.2). 

При этом особенности реализации ОССН соответствуют особенностями реализации 
ОС проекта ОеЫап СЛ/Ш_/шх, в частности: 

• поддержка последних версий стандартов в рамках проектов Ыпих Зіапдагд Вазе (І-ЗВ) 
[124] и Рііезузіет Ніегагску Зіапдагд (РНЗ)[ 113]; 

•наличие более одиннадцати официальных переносов (портов) на различные 
процессорные архитектуры; 

• наличие системы управления пакетами программ АРЦАсІѵапсесІ Раскадіпд ТооІ ) с 
жесткой политикой по отношению к разрабатываемому ПО, поддержкой разветвлённой сети 
репозиториев и стандарта механизма выбора предпочтительного ПО среди нескольких 
вариантов ( аііегпаііѵез ); 

• большое число (более 50 тысяч) пакетов совместимого прикладного ПО; 

• наличие системы отслеживания ошибок ВТЗ (Вид Тгаскіпд Зузіет), обеспечивающей 
высокое качество кода драйверов, системных сервисов и поддерживающей высокую 
стабильность функционирования производных дистрибутивов на базе ОеЫап (^N^/^іпиx 

Являясь производным дистрибутивом ОеЫап (^N^/^іпиx, ОССН официально 
поддерживает переносы на следующие архитектуры: 

• атсІ464 — процессоры Іпіеі и АМОс микропроцессорной архитектурой х86-64; 

•агте1,агтМ,ААгсМ64— 32- и 64-разрядные процессорные ядра разработки фаблесс 

компании АРМ ЫтііесІ; 

• з390х — 64-разрядное пространство пользователя для мэйнфреймов ІВМ Зузіет г; 

• МІРЗ ( тірз и тірзеі) — 32-разрядное процессорное ядро разработки фаблесс 
компании МІРЗ Тескпоіодіез, Іпс. Поддержка реализации процессорного ядра Р5600 
архитектуры МІР332 Пеіеазе 5 в системе на чипе ВЕ-Т1000 ( ВаікаІ-ТІ ) фаблесс комцании 
ВаікаІ ЕІесігопісз и систем на чипе 1890ВМ8Я «КОМДИВ64А-М» и 1907ВМ028 «КОМДИВ64- 
КНИ» разработки ФГУ ФНЦ «НИИСИ РАН » [2]; 

• РОѴѴЕП — процессорная архитектура разработки компании ІВМ (консорциум 
орепРОУѴЕР ). Поддержка реализации суперскалярных процессоров ІМВ РОѴѴЕП8 ( Тигізто 
ЗСМ) реализована в высокопроизводительных серверных платформах УАРОО VЕЗNIN 
компании УАРОО [90]. 



Вне рамок официальных переносов ОеЫап ОМІІ/Ипих версия 1.6 ОССН поддерживает 
процессорную архитектуру «Эльбрус», реализованную в процессорах Эльбрус-80, Эльбрус- 
1С + , Эльбрус-40 компании МЦСТ [29]. 

Существующие релизы дистрибутива ОССН базируются на указанных переносах 
ОеЫап СN^/^іпиx и собственных сборках для архитектуры «Эльбрус». Их обозначения 
отличаются редакцией дистрибутива и номером версии. Редакция дистрибутива определяет 
специфику дистрибутива: поддерживаемый перенос (аппаратная платформа) и область 
применения. Номер версии —две или три цифры определяют версию дистрибутива ОССН. 

В установленном дистрибутиве ОССН обозначение релиза указано в файле 
/еІс/азІга_ѵегзіоп.. Формат записи релиза: 

ЕО/Т/О/Ѵ Неіеазе (Сосіепате), где: 

•ЕЕ/770/Ѵ — редакция релиза дистрибутива (для ОССН имеет значение «8Е»); 

• Неіеазе — цифровое кодирование текущей версии релиза ОССН в формате ѴІІУ, где 
V — первая цифра релиза, связанная с его именем ( Сосіепате ), II — вторая цифра, 
отражающая текущую версию релиза, У— третья цифра, отражающая номер обновления в 
пределах текущей версии релиза (если таких обновлений не было, номер обновления 
отсутствует); 

• (Сосіепате) — имя релиза на латинице (связано с редакцией ООСН и первой цифрой 
релиза). В частности, для ОССН в качестве имен релизов используются названия городов- 
героев России. 

Также информацию о текущей версии релиза и имени релиза можно получить в 
консольном режиме с помощью команды отображения информации о дистрибутиве 
ІзЬ_геІеазеа. Пример вывода этой команды представлен на рис. 1.3. 

Существующие в настоящее время дистрибутивы и их именование для релизов ОССН 
версии 1.6 представлены в табл. 1.2, для релизов ОССН версии 1.4 и 1.5 представлены в 
табл. 1.3. 

В дальнейшем (если это специально не оговорено по тексту) рассматривается релиз 
«Смоленск» ОССН версии 1.6. Он основан на релизе ОеЫап ОЛ/Ш_/шх 9.4 (кодовое имя 
Зігеісіі). Это означает что в качестве пакетной базы этого релиза ОССН используется 
репозиторий ОеЫап СN^/^іпиx 9.4. Фактически, это задаёт базовую архитектуру релиза, 
которая дополняется: 

•регулярно выпускаемыми оперативными обновлениями безопасности версий пакетов, 
в функциональности которых были обнаружены те или иные уязвимости ; 
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Рис. 1.3. Вывод информации о текущей версии релиза и имени релиза 


Таблица 1.2 


Релизы ОССН версии 1.6 


Имя релиза 

Обозначение 

релиза 

Архитектура 

СВТ,для которых 

предназначен 

релиз 

Смоленск 

8Е 1.6 
(зтоіепзк) 

атсІ64 

(Х86-64) 

Персональные 
компьютеры (в том 
числе и 

планшетные) и 

серверы на базе 

Новороссийск 

8Е 16 

(поѵогоззіузк) 

АРМ 

процессоров Іпіе 1 и 
АМО 

Мобильные 

Севастополь 

ЗЕ 6.1.1 
(зеѵазіороі) 

МІР332 

Веіеазе 5 

терминалы 
(планшетные 
персональные 
компьютеры) и 

Севастополь 

ЗЕ 6.1.2 
(зеѵазіороі) 

МІРЗ арха- 
тектура 

КОІѴЮІѴ64 

встраиваемые 

системы 

Персональные 
компьютеры и 

серверы на базе 
процессоров ВЕ- 
Т1000 

Ленинград 

ЗЕ 1.6 
(іепіпдгасі) 

Эльбрус 

(ВаікаІ-Т1) 

Персональные 
компьютеры и 

серверы на базе 
процессоров 
18908ВМ8Я 
«КОМДИВ64- 
М»1907ВМ028 
«КОМДИВ64-КНИ» 







Имя релиза 

Обозначение 


Архитектура 

СВТ.для которых 


релиза 



предназначен 

релиз 

Новороссийск 

ЗЕ 4.0.1 


АРМ 

Мобильные 


(поѵогоззіузк) 



терминалы 


пакетная 

база 


(планшетные 


релиза 



персональные 
компьютеры) и 

Мурманск 

5Е 1.5 


ЗЗЭОх 

встраивае¬ 
мые системы 


ЗЕ 3.1 (тигтапзк) 



Тула 

пакетная 

релиза 

база 


Мейнфреймы ІВМ 





Зузіет г 


ЗЕ 1.4 



(29, 2І0, 212) 


ЗЕ 1.4 (ШІа) 



Маршрутизаторы, 

шлюзы, 





межсетевые 





экраны 





Персональные 





компьютеры и 

серверы на базе 





процессоров 

Эльбрус- 

80, Эльбрус-1 С + , 
Эльбрус-40 


Таблица 1.3 


Релизы ОССН версий 1.4 и 1.5 

• программами и сервисами с открытым исходным колом, разрабатываемыми в рамках 
концепции свободного ПО; 


•программами и сервисами, являющимися коммерческими продуктами; 

• программами и сервисами, являющимися собственной разработкой производителя 
АО «НПО РусБИТех». 

Детализация базовой архитектуры релиза относительно обобщенной архитектуры ОС 
на базе проекта (^N^/^іпиx представлена на рисунке 1.4 

Таким образом, архитектурно ОССН базируется на двух вариантах модульного ядра 
проекта ОМУ//_/шх версии 4.15.3-1: 






1 .КегпеІ Оепегіс — вариант ядра общего назначения, обеспечивающий 
функциональность ОССН, такую, как: 

• диспетчеризация аппаратных ресурсов компьютера между выполняющимися 
приложениями и поддержка вытесняющей многозадачности (многопоточности) 

• предоставление механизмов межпроцессного взаимодействия: 

• поддержка механизма виртуальной памяти; 

• поддержка стека драйверов запоминающих устройств / зіогаде сіеѵісе), 

• поддержка виртуального коммутатора файловых систем Ипих (Ипих ѴігіиаІ РІІе 
Зузіет Зѵѵіісіі); 

• поддержка стека сетевых протоколов ТСР/ІР версий 4 и 6. 
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Рис.1,40бобщенная архитектура ОССН 

2. КегпеІ НагсІепесІ — усиленный (защищённый) вариант ядра ОССН, обеспечивающий 
дополнительно с базовой функциональностью расширенные функции, связанные с защитой 
ядра, такие, например, как: 

•ряд функций модуля РаХ (например, ІЮЕНЕЕ и кегпехес), применяемых ранее в 
ОССН версий 1.4 и 1.5, устанавливающие правила доступа прикладных программ к 
адресному пространству памяти, что предотвращает несанкционированное выполнение 
кода, связанного с уязвимостями разыменования указателей или повреждения памяти 
{тетогу соггирііоп ); 

• функции, например, такие, как РІЕ ( РозШоп Іпсіерепсіепі ЕхесиІаЫез) и 83Р {Зіаск 
Зтазіііпд Ргоіесіог), предотвращающие переполнения стека, например, из-за неправильного 







использования массивов переменной длины ( Ѵегу І-агде Аггау), а также эксплуатации 
уязвимостей, использующих ошибки глубокой вложенности ( сіеер пезііпд) и рекурсивных 
функций; 

• функции, используемые ядром при копировании данных в/из пространства памяти 
прикладных программ ( изегзрасе ). Их использование гарантирует, что копии, передаваемые 
в/из кучи (Ііеар) и стека объекта, не превышают его размер (это предотвращает изменение 
объектов ядра или утечку данных из них); 

• функции, предотвращающие внедрение вредоносного кода в процессы путём 
перехвата начального потока управления. 

В качестве параметров конфигурирования исходного кода ядра релиза для получения 
варианта КегпеІ НагсІепесІ релиз ОССН использует рекомендации проекта К5РР ( КегпеІ Зеіі 
Ргоіесііоп Ргоіесі) [112] 

В общем случае ядро КегпеІ НагсІепесІ ориентировано на создание 
высокозащищенных, стабильных серверных платформ, обеспечивающих повышенную 
функциональную живучесть. Реализация 
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Рис. 1.5. Место функций НагсІепесІ КегпеІ в системе многоуровневой защиты ОССН 

перечисленных функций в КегпеІ НагсІепесІ является дополнительным уровнем 
защиты, наряду с мандатными управлением доступом (МАО) и контролем целостности ( 
МТС), а также, в перспективе, ролевым управлением доступом (ИВАС), реализованными в 
подсистеме безопасности РАЯ5ЕС на основе МРОСЛ АП-модели. Подобный 
многоуровневый подход усложняет нарушителю эксплуатацию потенциальных уязвимостей 
системы. В обобщённом виде он представлен на рис. 1.5. 

Бинарная совместимость прикладных программ и сервисов как с ядром КегпеІ Оепегіс, 
так и с ядром КегпеІ НагсІепесІ обеспечивается соответствующими уровнями АВІ (Арріісаііоп 
Віпагу Іпіегіасе). 

В качестве интерфейса прикладного ПО — АРІ ( Арріісаііоп Ргодгаттіпд Іпіегіасе) 
используется библиотека ЕтЬесІсІесІ ОИІІС ИЬгагу (ЕОИВС), принятая в качестве стандарта 
АРІ по умолчанию в проекте йеЫап СА/Ш./лг/х[141]. 

Функциональность ядер КегпеІ Оепегіс и КегпеІ НагсІепесІ расширяется совокупностью 
загружаемых модулей ядра — І_КМ (І-оасІаЫе КегпеІ Мосіиіез), ряд из которых является 
невыгружаемыми. 

К ним в первую очередь, относятся: 

1) модуль сІід5Ід_ѵегііко, реализующий функции проверки цифровой подписи бинарных 
файлов формата Е/_Р[63], запускаемых в ходе инициализации системы и пользовательских 
сеансов; 

2) модули, относящиеся к стандарту /_5М (Ипих Зесигііу Мосіиіез) [145] и реализующие 
функциональность подсистемы безопасности РАНЗЕС. К ним относятся: 

• модуль рагзес.ко — базовые функции подсистемы безопасности РАНЗЕС ; 

• модуль рагзес-сііз.ко —расширение виртуального коммутатора файловых систем 
Ипих ѴЕЗ, поддерживающего ЗИІА вариант спецификации протокола СІЕЗ для организации 
защищённого удалённого файлового обмена [72]. В качестве основы модуля рагзес-сііз.ко 
используется модуль із-сііз.со, доработанный разработчиками ОССН с целью поддержки 
мандатных меток для протокольных объектов СІЕЗ. 

Подсистема безопасности РАНЗЕС расширяет стандартную для проекта СЛ/Ш./шх 
систему привилегий, предназначенную для передачи учётным записям пользователей прав 
выполнения определённых действий администратора (пользователя гооі ), поддержкой 
описанной в главе 2 иерархической МРОСЛ ДП-модели. 

В общем случае она реализована в соответствии с рекомендациями разработки /_$М 
Мосіиіе Роіісу Епдіпе и функционально представляет собой реализацию монитора 
безопасности, принимающего решение о доступе процессов, выполняющихся в изегзрасе , к 
затребованным ими объектам режима зузіетзрасе . Особенностью реализации такого. 



модуля ІЗМ является использование совокупности механизмов перехвата (Іюокз), которые 
перехватывают и анализируют аргументы запросов процессов и, в соответствии с 
установленными правилами доступа МРОСЛ ДП-модели, разрешают или запрещают их. 
Обобщённое представление процесса функционирования подсистемы безопасности 
РАРЗЕС даётся на рис. 1.6. 

Подсистема Р РАРЗЕС поддерживает следующие расширенные привилегии: 

• посылать сигналы процессам, игнорируя дискреционные и мандатные правила 
управления доступом; 

• право посылать мандатную метку и устанавливать другие привилегии; 

• право менять мандатные метки файлов; 

• право управлять политикой аудита: 

• право игнорировать мандатную политику при чтении и поиске файлов (исключая 
функцию записи); 

• право создавать привилегированный сокет и менять его мандатную метку; 

• право изменять время доступа к файлу; 

• право игнорировать мандатную политику по уровням и категориям; 

• право устанавливать привилегии на файлы; 
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Рис. 1.6. Схема функционирования подсистемы безопасности РАЯ8ЕС 


• право устанавливать любой непротиворечивый набор привилегий для выбранного 
процесса; 

•право менять мандатную точку сетевого соединения. 

Организация пользовательских сессий в ОССН реализуется традиционно для проекта 
(^N^/^іпиx как консольном (интерфейс командной строки — СИ Соттапд Ипе Іпіегіасе), так 
и графическом (графический интерфейс пользователя — СИ Соттапд Ипе Іпіег(асе) 
режимах. 

Консольный режим пользовательских сессий может быть организован в среде 
следующих командных интерпретаторов (оболочек): 

• ЬазЬ (Войте адаіп зЬеІІ) — ѲІМІІ версия РОЗІХ совместимого интерпретатора з/?; 

•сіазіі (ОеЫап АІтдиізі зііеіі) — СІМІІ версия РОЗІХ совместимого интерпретатора аз. 
Функционально совместим с интерпретатором Ьазіі, и, за счёт отсутствия ряда функций, 
является более производительным (например, при обработке з/7е//-сценариев). 

Графический режим пользовательских сессий организован с помощью защищённой 
графической подсистемы Р/у. Это обобщённое обозначение следующих функциональных 
компонентов ОШ: 

• ІІу-ѵѵт(Пу ѴѴІпсІоѵѵ Мападег) —менеджер окон , именуемый в Руководстве 
пользователя ОССН как «Рабочий стол Ну» и реализующий традиционную для менеджеров 
окон функциональность: 

о поддержку множества рабочих столов ( Яезкіорз ) и переключение между ними; 

о доступ к запускаемым приложениям и функциям управления сессией с помощью 
меню «Пуск»; 

о управление окнами ОШ-приложений; 

о управление переключением фокуса работы с ѲШ-приложениями на основе 
панели задач; 

о управление блокировкой пользовательской сессии; 



о управление оповещениями о событиях на основе области уведомлений 
(поМісаііоп агеа); 

•ііу-сіт и ІІу-ддт (Ну Оізріау Мападег)- дисплейный менеджер графической подсистемы 
Ну (представлен серверным ІІу-сІт и клиентским компонентами). Реализует функции 
ОІЛ Іодіп : 

о запуск локальной или удалённой сессии учётной записи пользователя; 
о процесс входа (идентификация и аутентификация) пользователя в систему. 
Основой защищённой графической подсистемы Ну является графический 
сервер Х.Огд Зегѵег —реализация X ѴѴІпсіоѵѵ Зузіет с открытым исходным кодом. 
Базовые библиотеки Ну, предоставляющие ѲШ-приложениям функции формирования 
требуемых визуальных компонентов (3111, базируются как на кроссплатформенной 
платформе 015 [128], так и на функциональных решениях разработчиков ОССН: 

• Нуиі — высокоуровневая библиотека компонентов, основанная на библиотеке //Ьф5- 
диі платформы 015; 

• кі5 — высокоуровневые библиотеки компонентов платформы КОЕ Егатеѵѵогк (версия 
5), также базирующиеся на библиотеке ІіЬді5-диі ; 

• ІІусоге — библиотека, не зависящая от библиотек платформы 015, выполняющая 
сервисные функции (взаимодействие с ІІу-ѵѵт, управление абсолютными путями к служебным 
файлам рабочих столов, доступ к коллекциям иконок, обработка конфигурационных файлов 
0111-приложений), являющаяся функциональным решением разработчика ОССН. 

Благодаря правилам для создания приложений ОССН, включаемых в состав рабочего 
стола Ну или взаимодействующих с ним, вне зависимости от представленных выше 
высокоуровневых библиотек компонентов, появляется возможность добиться: 

• единообразия внешнего вида 0111-приложений, их внутренней структуры и поведения; 

• унификации сборки и установки 0111-приложений, 

• простой модификации и сопровождения 0111-приложений. 

Функциональность ОШ компонентов ІІу-сіт и ІІу-дсІт расширяется функциями 
библиотеки ІіЬрагзес-тас-ді5-1 , предоставляющей доступ к функциям подсистемы 
безопасности РАНЗЕС и содержащей набор классов для работы с мандатными атрибутами. 
На основе этих функций: 

• процесс ОІЛ Іодіп (приложения Иу-ёт и Иу-цсіт) получает возможность формирования 
диалога выбора атрибутов мандатных управления доступом и контроля целостности учётной 
записи пользователя при организации ее ѲШ-сессии; 

• менеджер окон (приложение ІІу-ѵѵт) получает возможность создания диалога для 
установки атрибутов мандатных управление доступом и контроля целостности объектов 



файловой систе-мы, а также графической визуализации мандатного контекста окон <3111- 
приложений; 

• графический сервер Х.Огд Зегѵег получает возможность определения привилегий 
ХОгд клиента (ѲІІІ-приложения) и передачи их с использованием модифицированного X- 
протокола менеджеру окон ІІу-ѵѵт, который и выполняет привилегированные операции в ходе 
запуска (3111-приложений с различными мандатными контекстами. При этом на рабочем столе 
Р/у выполняется отображение: 

•мандатного контекста пользовательской сессии в области уведомлений ( поіііісаііоп 

агеа ); 

• мандатного уровня каждого окна; 

• мандатного уровня всех С(/1 -приложений, размещённых на рабочем столе Р/у; 
•мандатного уровня окна для локально или удалённо запущена приложений (цветовое 

обрамление (рамка) окна приложения). 

В табл. 1.4 представлены версии ядра (^N^/^іпиx, базовых библиотек, приложений и 
средств разработки дистрибутива ОССН. 

Кроме базовых компонентов, библиотек и средств разработки в состав дистрибутива 
ОССН входит общее ПО, обеспечивающее поддержку следующих функций: 


Таблица 1.4 

Релизы базовых компонентов, библиотек и средств разработки дистрибутива ОССН 


Компоненты 

Номер версии 

Ядро 6Л/Ш-/шх (Ипих КегпеІ) 

4.15.3 

Системная библиотека едІіЬс (ЕтЬеМес] 
дІіЬс) 

2.24 


6.3.10 

Компилятор дсс 

7.12 

Отладчик дсІЬ 

2.28 

Набор программ сборки объектных 
файлов ЫпиШз 

4.1 

Утилита автоматизации процесса 

компиляции таке 

2.4.44 

Реализация протокола /_ШР орепісіар 

1.1 ОРЗ 

Криптографический пакет ОрепЗЗІ 

4.4 

Командный интерпретатор Ьазк 

1.19.6 

Система Х.Огд 

5.10.1 




Библиотека СІІІ-фрейворка 015.0 ІіЬді5 

2.13.11 

Менеджер окон Чу-ѵѵт 



• обработка документальной информации (текстовые, табличные редакторы и 
средства создания презентационных материалов и доступа к реляционным базам данных); 

• сканирование, печать и передача документальной информации; 

• доступ к информации, хранящейся в реляционных базах данных, включая поддержку 
ПО «1С» и ПО для работы с географическими объектами РозіОІЗ] 

• доступ к информации через сервер гипертекстовой обработки 

данных (НТТР-сервер и клиент); 

• обмен сообщениями электронной почты (5МТР/ІМАР-серверы и клиент); 

• работа с графикой и мультимедиа (звук, видео). 

Наименование и версии перечисленных видов общего ПО представлены в табл. 1.5. 

ОССН обеспечивает поддержку развёртывания, конфигурирования и эксплуатации 
развитых, масштабируемых, высокодоступных, отказоустойчивых сетевых инфраструктур, 
которые базируются на технологиях: 

• централизованного управления сетевыми ресурсами и политиками безопасности на 
основе доменной архитектуры ( Оотаіп пеіѵѵогкіпд) - , 

• виртуализации вычислительных и сетевых ресурсов ( ѴігІиаЧгаІіоп іескпоіоду) - , 

• распределенных и/или параллельных вычислений на основе кластеров ( СІизіег 
сотриііпд) с целью: обеспечения высокой доступности сетевых сервисов ( Нідкі аѵаіІаЫІіІу) 
и/или повышенной производительности вычислительной системы (НідМ-регІогтапсе 
сотриііпд) 

Таблица 1.5 


Наименование и версии общего ПО дистрибутива ОССН 


Наименование общего ПО 

Версия общего ПО 

Средства обработки документальной 
информации 

Офисный пакет ИЬгеОНІсе 

5.2.7 

Средства сканирования .печати и 
передачи документальной информации 

3.17.10 

Комплекс программ Неѵѵіеіі-Раскагсіз 
ііпих Ітадіпд апсі Ргіпііпд 

2.2.1 

Средства доступа к информации 
.хранящейся в реляционных базах 
данных СУБД Роз1дге80Ч 

9.2.14 и 9.6 

Средства доступа к информации через 
сервер гипертекстовой обработки 

2.4.25 

данных 

ѴѴеЬ-сервер АрасМе2 

54.0.2 

ѴѴеЬ-браузер Рігеіох 

66.033.59.117 





ѴѴеЬ-браузер СМготіит 


Средства обмена сообщениями 
электронной почты 

4.89 

Сервер электронной почты Ехіт4 
Сервер электронной поты Ооѵесоі 

2.2.33 

Клиент электронной почты ТИипсІегЬігсІ 

52.6.0 

Средства мнговенного обмена 
сообщениями (іпзіапі теззадіпд) ХМРР 

1.3.425 

клиент Рзі+ 

Средства для работы с графикой и 

2.8.18 

мультимедиа 

Редактор растовой графики ѲІМР 

0.92.1 гі 5371 

Редактор векторной графики Іпкзрасе 

2.78 

Редактор трехмерной компьютерной 

1.1.3 

графики ВІепсІег 

2.1.2 

Набор звуковых драйверов и микшер 
АІ_5А 

Аудиоредактор АШАСІТѴ 
Медиапроигрыватель ѴІ_С 

3.0.0 


При проектировании сетевых инфраструктур указанные технологии могут применяться 
как по отдельности, так и в совокупности, что обеспечивает высокую гибкость их 
конфигурирования и модификации. 

Особенностью использования указанных технологий в рамках ОССН является 
возможность формирования защищённых вариантов сетевых инфраструктур, использующих 
единую политику безопасности, базирующуюся на механизмах подсистемы безопасности 
РАН 5 ЕС. 

Взаимосвязь представленных технологий в рамках создания защищённых 
распределенных вычислительных инфраструктур и централизованного управления их 
ресурсами на основе единой 

политики безопасности, поддерживаемой РАН5ЕС, показана на рис.1.7 

Базовой технологией являются сервисы формирования доменной 
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Рис. 1.7. Взаимосвязь технологий поддержки защищённых распределенных 
вычислительных и сетевых инфраструктур в ОССН 

сетевой инфраструктуры. ОССН поддерживает несколько технологий 
формирования, имеющих разное функциональное назначение: 






• Азіга Ипих Оотаіп (АЬО) — традиционная для релизов ОССН доменная архитектура. 
Обеспечивает формирование защищённого единого пространства пользователей (ЕПП) с 
защищенной щённой авторизацией на контроллере домена и поддержкой политики 
безопасности хранимых в домене данных и потоков информации на основе функциональных 
возможностей подсистемы безопасности РАПЗЕС. Инфраструктура АЬО обеспечивает 
решение задач резервирования данных контроллера домена АІ_й и установления 
доверительных отношений между основными и резервным контроллерами. Она является 
функциональным решением разработчика ОССН и более подробно рассматривается в главе 
3 . 

•РгееІРА (Ргее ІсІепМу, Роіісу апд Аисііі) —доменная инфраструктура, формируемая в 
рамках проекта с открытым исходным кодом РгееАРІ, доработанная разработчиком ОССН с 
целью поддержки политики безопасности хранимых в домене данных и потоков информация 
на основе функциональных возможностей подсистемы безопасности РАР5ЕС [68]. Базовым 
отличием доменной архитектуры РгееАРІ от архитектуры АІО является возможность её 
масштабирования при создании как доменной инфраструктуры с несколькими контроллерами 
домена, так и интеграции с уже существующими защищенными доменными 
инфраструктурами на базе РгееАРІ, путём установления внутри-и междоменных 
доверительных отношений на основе функций Рогезі Тгизі РгееАРІ полностью поддерживает 
стандарты Рогезі Тгизі описанные в [96], и обеспечивает как формирование доверительных 
отношений внутри доменного леса, так и доверительных отношений между лесами доменов 
с поддержкой сквозной (через лес) аутентификации и авторизации ( Сгозз-Рогезі 
АиІЬепІісаІіоп ). Более подробно возможности технологии РгееАРІ в ОССН рассматриваются 
в главе 3. 

• ЗатЬа ОС (ЗатЬа 4 ОотаіпСопігоІІег ) — контроллер домена на основе пакета 
программ ЗатЬа (версии 4.x). Является реализацией доменной инфраструктуры Місгозоіі 
Асііѵе Оігесіогу Оотаіп Зегѵісез для 1/1 /іпсіоѵѵз Зегѵег 2003/2008 [95] на базе ОССН с 
возможностью подключения клиентов домена на основе пользовательских и серверных 
сборок ОС семейства Місгозоіі ѴѴіпсІоѵѵз.Позволяет создавать объекты групповой политики 
( СРО-Сгоир Роіісу ОЬіесІз) для всех клиентов домена. 

Одним из достоинств ЗатЬа ОС является возможность использования в качестве 
инструментов управления доменными службами пакета инструментов Місгозоіі Ветоіе 
Зегѵег Адтіпізігаііоп Тооіз (В5АТ) [131], что делает её эффективным средством в случае 
необходимости выполнения миграции с доменной инфраструктуры Місгозоіі Асііѵе Оігесіогу 
на платформу ОССН. 

Технологии ЗатЬа ОС присущи недостатки, ограничивающие функциональность её 
использования. К основным из них относятся: 



• ограничения на число записей об объектах в каталоге Асііѵе йігесіогу, связанные с 
32-разрядной архитектурой ТгіѵіаІ йаіаВазе (базы данных, по умолчанию используемой 
сервисами ЗатЬа), а также на размер файлов ІЬЬ в 4 гигабайта, что позволяет создавать не 
более десяти тысяч записей; 

• отсутствие поддержки взаимодействия с контроллерами домена на базе ОС ѴѴІпЬоѵѵз 
Зегѵег 2012 и ОС Ѵ/Ыоѵѵз 2012 Н2; 

• отсутствие поддержки МІТ КегЬегоз и функции ЗЮ РіІІегіпд , что не позволяет 
организовать защищённую аутентификацию клиентов домена. 

подробно возможности и ограничения технологии ЗатЬа ОС в ОССН рассматриваются 
в главе 3. 
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Рис. 1.8. Функциональность применения технологий доменной архитектуры на базе ОССН 




Перечисленные технологии доменной инфраструктуры базируются на ОрепіОАР — 
открытой реализации протокола /_ШР [56]. Для формирования ключей шифрования, 
сертификатов открытых ключей и выполнения шифрования данных 55/-/Г5/-, соединений в 
состав дистрибутива ОССН входит криптографический пакет Ореп-55і- [143]. 

В обобщённом виде функциональность применения технологий А/.0, РгееІРА и ЗатЬа 
йС в составе распределенных инфраструктур на базе ОССН представлена на рис. 1.8. 

Ещё одной особенностью рассматриваемого релиза ОССН версии 1.6 является 
включение в его состав технологий виртуализации, обеспечивающих возможность 
формирования локальных и распределенных виртуальных инфраструктур. Их использование 
существенно повышает эффективность применения АСЗИ с точки зрения 
масштабируемости, высокой доступности и отказоустойчивости сетевых и вычислительных 
ресурсов. 

Основой подсистемы виртуализации в ОССН является технологический стек, 
состоящий из следующих уровней. 

1. Доступ к аппаратному обеспечению физического хоста (в терминологии стека — узла 
Л/ос/е). Этот уровень в ОССН представлен программным обеспечением КѴМ (КегпеІ-Ьазед 
Ѵігіиаі МасІііпе)[ 99], обеспечивающим поддержку технологий аппаратной виртуализации ІпіеІ 
ТѴ (ѴігіиаЧіаііоп Тесііпоіоду) и АІѴЮ ЗѴМ (Зесиге Ѵігіиаі МасІііпе) [135]. Реализован в виде 
модулей ядра кѵтко фазовый сервис виртуализации), кѵтіпіеІко,кѵтатсіко{прои,ессорно- 
специфические сервисы виртуализации) 

2.Эмуляция аппаратного обеспечения для гостевых ОС (в терминологии стека — 
доменов). Представлен модификацией гипервизора ОЕМІІ, представляющим собой 
компонент пользовательского режима КѴМ, который использует интерфейс уровня доступа к 
аппаратному обеспечению узла для настройки адресного пространства гостевых доменов и 
эмуляций видеоадаптеров и устройств ввода-выводы. 

3.Управления виртуализацией. Представлен набором инструментов ІІЬѵігі 
включающим: 

•библиотеку АРІ виртуализации на базе проекта с открытым исходным кодом [122]; 

•сервис (демон) ІіЬѵігісІ ; 

•СИ-интерфейс пользователя ѵігзіі. 

Взаимодействие уровня управления виртуализацией и гипервизора ОЕМІІ 
осуществляет с использованием протокола ОМР(ОЕМІІ тасіііпе РгоіосоІ). 

Указанные уровни стека виртуализации ОССН могут использоваться как для 
локального создания и управления, так и для защищенного удалённого управления 



гостевыми доменами. В последнем случае в качестве протоколов удалённого доступа к 
рабочему столу гостевого домена могут применяться: 

•ПЕВ(Петоіе Егате Виііег) системы 1/Л/С 

•РОР(Ретоіе Оезкіор РгоіосоІ) 

•8РІСЕ(ЗітрІе РгоіосоІ іо г Іпсіерепсіепі Сотриііпд Епѵігоптепіз) 

Сервис ІіЬѵіііб поддерживает следующие технологии защищенной идентификации и 
аутентификации для доступа к ресурсам гостевых доменов: 

•набор средств предоставления сервиса аутентификации ЗАЗІ- (Зітріе Аиіііепіісаііоп 
апсі Зесигііу І-ауег), которые в ОССН реализован с поддержкой сетевого протокола 
аутентификации КегЬегоз и более подробно рассматривается в главе 3; 

•система аутентификации на уровне сервиса 55Н,использующая алгоритмы 
электронной подписи РЗА и йЗА 

•протокол защиты транспортного уровня ТІ-3(Тгапзрогі І-ауег Зесигііу), базируется на 
спецификации протокола 53І_ 3.0. 
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Рис. 1.9. Локальный стек виртуализации на базе ОССН 

В обобщённом виде схемы локального и удалённого управления стеком виртуализации 
ОССН представлены на рис. 1.9 и 1.10. 

Повышение эффективности использования рассмотренной выше технологии 
виртуализации реализуется в ОССН включением средств организации 
высокомасштабируемых (НЗ — Нідіі ЗсаІаЬІІІіу) отказоустойчивых кластерных систем, в том 



числе поддерживающих режим высокой доступности {НА — Нідіі АѵаіІаЫІііу). Основой этих 
кластерных систем являются следующие проекты свободного ПО, модифицированные 
разработчиком ОССН с целью поддержку функций подсистемы безопасности РАНЗЕС: 




Рис. 1.10. Схема удаленного управления стеком виртуализация на базе ОССН 

Расетакег- продукт сообщества разработчиков СІизІегІ-аЬз [44]. Он является 
менеджером ресурсов кластера высокой доступности и представлен модулями ПО, 
выполняющимися на узлах кластера и реализующими функцию минимизации времени 
простоя требуемых сервисов (в терминах технологии — ресурсов). В рамках этой функции 
Расетакег решает следующие задачи: 

• обнаружение и восстановление после сбоев на уровне узлов кластера и 
выполняющихся сервисов, 

• обеспечение целостности данных путём блокирования отказавших узлов кластера; 

• поддержка разнообразных стандартов интерфейса ресурсов (реализация 
управления ресурсами на уровнях сценария на большинстве доступных скриптовых языков); 

• поддержка (опциональная задача) распределенного общего хранилища данных; 

• поддержка разнообразных схем резервирования (асІіѵе/ра55іѵе,М+1 и тд.); 

• поддержка автоматически реплицируемой конфигурации, которая может быть 
обновлена с любого узла кластера; 





•поддержка внутрикластерных отношений между сервисами; 

• поддержка расширенных типов сервисов, таких как клоны ресурсов (сервисы, которые 
должны быть активны на нескольких узлах кластера), ресурсы с состоянием (клоны, которые 
могут работать в одном из двух режимов) и контейнерные сервисы. 

Согозупс- ( Согозупс СІизіег Епдіпе) — продукт сообщества разработчкиво 
Кегпеіогд, реализующий коммуникационные возможности кластерной системы [43]. 
Функциями Согозупс являются: 

• отслеживание состояния сервисов, функционирующих в рамках кластера; 

• оповещение сервисов о смене активного узла кластера; 

• отправка одинаковых сообщений сервисам на всех узлах кластера; 

• предоставление администратору кластера доступа к базе данных с конфигурацией 
и статистикой, а также отправка уведомлений о ее изменениях. 

В обобщённом виде схема отказоустойчивого кластера на основе продуктов Расетакег 
и Согозупс представлена на рис. 1.11. 

Сервисы, относительно которых организуется отказоустойчивый кластер, фактически 
являются кластеронезависимым уровнем. Их важной особенностью является возможность 
управления (старт, 

























Рис.1.11. Схема организации отказоустойчивого кластера на основе продуктов Расетакег и 

Согозупс 

остановка, перезапуск, мониторинг состояния) с помощью сценариев, именуемых 
агентами сервисов. В зависимости от спецификации, применяемой для формирования 
агентов, они делятся: 






• на агенты /_$В ресурсов — сценарии, поддерживающие Ипих ЗіапсІаП Вазе Соге 
Зресіксаііоп (размещаются в стандартном для этой спецификации каталоге инициализации 
/еіс/іпіі.сі); 

• на агенты ОСР ресурсов — сценарии, поддерживающие спецификацию Ореп 
Соппесііѵііу Роипсіаііоп , (размещаются в стандартном для этой спецификации каталоге 
инициализации / изг/ІІЬ/осІ/гезоигсе.сі/ргоѵісіег) . 

Совокупность сервиса и управляющего им агента (агентов) с точки зрения менеджера 
кластеров Расетакег является ресурсом кластера. Вне зависимости от применяемой 
спецификации агентов ресурсы кластера можно объединить в группу ресурсов, под которым 
понимается логическое объединение (список) ресурсов, функционирующих на одном узле 
кластера, которые инициализируются и останавливаются в определённом порядке. Таким 
образом, при сбое или отказе одного из ресурса входящих в группу, эта группа 
“перемещается” (инициализируется) на другой узел кластера. 

В рамках предоставленной выше инфраструктуры отказоустойчивого кластера в ОССН 
включены средства поддержки высокой доступности НА за счет введения избыточности к 
точке входа в тот или иной сервис устраняющие тем самым единую точку отказа (ЗРОР, 
5 іпдіе Роіпі Оі Раііиге). Средства поддержки режима высокой доступности позволяют 
сервисам автоматически перезапускать или перенаправлять задачи на другой узел кластера 
(ведомый узел) в случае сбоя на ведущем узле, поддерживающем данный сервис. Таким 
образом, в составе кластера должен быть компонент мониторинга возникающих на ведущем 
узле ошибок и сбоев и перенаправления задач с ведущего узла на ведомый узел и обратно 
в случае восстановления функциональности ведущего узла. 

Таким компонентом в ОССН является кеераііѵес I — демон поддержки мониторинга 
сервисов кластера и автоматического перенаправления трафика запросов/откликов 
ведомому узлу кластера в случае, если ведущий узел не отвечает. То есть кеераііѵесі 
выступает в роли монитора сбоев и балансировщика нагрузки (ІоасІ Ьаіапсег) в кластере с 
избыточностью (ведущим и ведомым узлами одинаковой функциональности) — НА- кластере. 

Основой функционирования демона кеераііѵесі является плавающий (виртуальный) ІР- 
аадрес ( РІоаііпд ІР, ѴІР — Ѵігіиаі ІР) —публичный статический ІР-адрес, присвоенный одному 
из узлов кластера. Он не подменяет основной публичный ІР-адрес узла, а является 
дополнительным адресом, с помощью которого можно получить доступ к узлу, за которым 
этот адрес закреплён. Фактически ѴІР выполняет функцию шлюза, с помощью которого 
учётные записи пользователей взаимодействуют с сервисом, развёрнутым в НА-кластере. В 
обобщённом виде схема НА-кластера, основанного на использовании кеераііѵесі, 
представлена на рис. 1.12. 



Функционирование сервисов в рамках отказоустойчивой, высокодоступной кластерной 
инфраструктуры, в большинстве случаев, требует развёртывания соответствующей системы 
хранения данных. К ней,также как и к механизмам управления сервисами на уровне кластера, 
предъявляются требования по масштабируемости, надёжности хранения и высокой 
доступности данных. 

С целью создания подобной системы хранения данных ОССН одержат средства 
формирования распределенной файловой системы на основе проекта с открытым исходным 
кодом СерІі[ 69], который базируется на программно-определяемой объектно- 
ориентированной файловой системе, создаваемой поверх существующей системы хранения 
данных кластерной инфраструктуры. Основными функциями Серіі являются: 

• распределенное в рамках узлов кластера хранение данных пользователей и 
сервисов, прозрачное с точки зрения доступа к ним; 



Ведомый (Раззіѵе) узел 


НА-кластер 

Рис. 1.12. Схема организации НА-кластера на основе сервиса кеераііѵесі 
• репликация данных между локальными системами хранения данных узлов кластера с 
целью повышения отказоустойчивости системы хранения и обеспечения высокой 
доступности данных; 











• распределение нагрузки между локальными системами хранения данных узлов 
кластера с целью обеспечения высокой доступности данных. 

Как объектно-ориентированная система Сер/? определяет единицу хранения данных 
как объект, который на нижележащих уровнях системы хранения узлов кластера 
отображается в традиционный стек системы хранения, основанный на таких логических 
единицах хранения, как дисковые разделы (рагііііопз) и кластеры (сіизіегз) файловых систем 
различных типов. Подобный подход позволяет абстрагировать алгоритмы функционирования 
Сер/? от реальной организации систем хранения на отдельных узлах кластера, обеспечивая 
поддержку гетерогенных с точки зрения локальных файловых систем узлов. 

Логической единицей, определяющей хранилище данных в Сер/?, является 
объектное устройство хранения 050 (ОЬ/ес/ Зіогаде Оеѵісе). Функции 030 включают: 

• хранение данных, представляемых объектами Сер/?/ 

• обработку пользовательских запросов на доступ и манипулирование данными; 

• взаимодействие с другими 030 в рамках решения задач доступа к данным, 
распределенных между несколькими 030, их репликации и восстановления, в случае 
сбоя и отказа 030. 

050 представлен: 

• физическим устройством хранения данных, подключённым к узлу кластера; 

• процессом-демоном, управляющим доступом к этим данным. 

Физическим устройством, чаще всего, является диск, но может использоваться и 
НА/Р-массив или сетевое хранилище (І\ІАЗ) на базе протокола /505/. Пространство 
устройства хранения при этом разделяется на две части: раздел журнала (функция 
журналирования транзакций с объектами является аналогичной таковой в традиционных 
файловых системах с журналированием) и раздел хранения данных, в котором размещаются 
объекты. 

Следующим логическим уровнем Сер/? является группа хранилищ (РО — РІасетепі 
Огоир) — совокупность взаимосвязанных, с точки зрения задач репликации данных, 050. 
Число 050 в группе хранилищ определяется параметром «фактор репликации». При этом 
вне зависимости от значения этого параметра один из 050 является первичным при 
размещении хранимых объектов, а остальные — 030-репликами, в которых размещаются 
реплицируемые копии хранимых на первичном 050 объекты. Сбой или отказ любого / 050 
приводит к исключению его из всех групп хранилищ, в которых он был зарегистрирован. При 
этом система управления Серб выберет новый работоспособный 050 и благодаря наличию 
реплик объектов в других 050 группах хранилищ восстановит на нем состав хранимых 
объектов. При этом любой 050 может одновременно принадлежать нескольких группам 
хранилищ, являясь для одних их них первичным 050> а для других 030-репликой. 


Более высоким логическим уровнем Серіі является пул (РооІ), представленный 
совокупностью групп хранилищ, объединённых в соответствии с типом хранимых данных 
(например, образы виртуальных машин облачной инфраструктуры или данные, поддержи¬ 
ваемые сервисами хостинга). Параметрами, определяющими организацию конкретного пула, 
являются: 

• фактор репликации (параметр, аналогичный такому же для от дельной группы 
хранилищ); 

• минимальное число доступных («живых») реплик объекта, не обходимое для 
получения клиентом Серіі подтверждения успешной записи объекта в инфраструктуре 
Серіі; 

• политика репликации объектов в пуле, определяющая инфраструктурный уровень 
репликации (например, в рамках отдельных 050 нескольких серверных стоек одного 
центра обработки данных, нескольких таких центров). 

Благодаря подобной многоуровневой логической структуре с гибко настраиваемым 
фактором репликации объектов логика хранимых в объектах Серіі данных будет 
максимально соответствовать требованиям инфраструктур отказоустойчивых и 
высокодоступных кластеров, рассмотренных выше. 

Система управления Серіі представлена множеством мониторов, реализуемых 
соответствующими процессами-демонами. Монитор — логический узел Серіі, хранящий 
карту доступных в данный момент 050 (СНІІЗН-карту). Эта карта формируется на основе 
логической (центры обработки данных, залы, ряды, стойки, узлы) и физической (диски и/или 
другие устройства хранения данных) структур кластера, в рамках которого развёртывается 
Серіі. При этом карта не содержит конкретные пути к объектам, хранимым в 050. Клиент 
Серіі формирует запросы к монитору с целью получения карты доступных 050, а доступ к 
объектам конкретного 050 клиент выполняет самостоятельно с использованием протокола 
СНІІЗН (СопІгоІІесІ Неріісаіесі ІІпсІег ЗсаІаЫе Назіііпд), однозначно идентифицирующего 
каждый хранимый объект на основе хеша его имени. 

В зависимости от масштаба хранилища на базе Серіі поддерживается один или 
более мониторов, распределяющих между собой нагрузку по обработке запросов клиентов. 
Согласованность карты доступных 050 поддерживается протоколом достижения консенсуса, 
для работоспособности которого требуется нечётное число мониторов. При невыполнении 
этого условия хранилище на базе Серіі блокируется во избежание рассогласования реплик 
СНІІЗН-карт. Мониторы могут выполняться на тех же узлах кластера, которые 
поддерживают процессы-демоны 050, или же для их выполнения могут использоваться 
выделенные узлы кластера. 



Клиенты Серіі могут не использовать логику организации хранилища на основе 
объектов, а получать доступ к данным на основе традиционных запросов к файловым 
системам. С целью поддержки такой возможности Серіі реализует уровень файловой сис¬ 
темы СерІіЕЗ (Серіі ЕІІе Зузіет), для обработки запросов в котором используются МОЗ (Меіа 
йаіа Зегѵег) — узлы Серіі, поддерживающие метаданные уровня СерІіЕЗ. Драйвер файловой 
системы СерІіЕЗ реализуется ядром ОССН, что позволяет монтировать ее, например, с 
помощью механизма ЕІІЗЕ (Еііезузіет іп ІІЗЕгзрасе). 

В обобщённом виде структура распределенного хранилища данных на основе 
проекта Серіі представлена на рис. 1.13. 



Для администрирования распределенной системы хранения данных на базе проекта 
Серіі в составе дистрибутива ОССН имеется СІ_2-утилита серіісіеріоу, устанавливаемая на 
одном из узлов- мониторов или на отдельно выделенном узле. Функциональность утилиты 
серіісіеріоу позволяет конфигурировать уровни инфраструктуры и логики репликации, а также 
обращаться к мониторам Серіі для получения актуальной информации об активности 050, 
входящих в состав Серіі. При этом необходимо учитывать, что ОССН не поддерживает 
развёртывание компонентов Серіі при активном режиме мандатного контроля целостности 
на узлах кластера. 











































































































































В рамках рассмотренных выше средств развёртывания масштабируемых 
отказоустойчивых высокодоступных инфраструктур ОССН может использоваться в качестве 
платформы программного комплекса средств виртуализации (ПК СВ) «Брест», который со¬ 
держит: 

• средства управления средой виртуализации и кластерами, сформированными 
рассмотренными выше средствами, входящими в состав ОССН; 

• средства мониторинга состояния кластеров и развёрнутой инфраструктуры 
виртуальных машин и распределенных хранилищ данных. 

При этом ПК СВ «Брест» выступает в роли платформы конфигурирования и 
эксплуатации средств, включённых в состав ОССН. Структурно взаимодействие компонентов 
ПК СВ «Брест» и ОССН представлено на рис. 1.14. 

Таким образом, ключевой особенностью дистрибутива ОССН является то, что в его 
состав входят механизмы защиты, обеспечивающие реализацию следующих функций: 


Рис.1.14.0рганизация масштабируемой инфраструктуры на основе ОССН и ПК СВ 
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• аутентификация пользователей с использованием инфраструктуры РАМ (РІиддаЫе 
АиМепНсаНоп Мосіиіез) [123] локально или в рамках ЕПП, а также двухфакторная 
аутентификация на основе цифровой подписи и инфраструктуры открытых ключей, 
поддерживаемых внешним носителем аутентификационной информации «Рутокен» 

И; 

• идентификация пользователей с использованием модульного окружения Л/55 (Мате 
Зегѵісе Зѵѵіісіі) локально или в рамках ЕПП [80]; 






• дискреционное управление доступом процессов к ресурсу поддержкой стандартов 
МіпітаІ АО. и Ехіепсіесі АО. [127]; 

• мандатные контроль целостности и управление доступом процессов к ресурсам на 
основе МРОСЛ ДП-модели, реализуемое на уровнях механизма межпроцессного 
взаимодействия, включая файловые системы ргос и ітріз, стек протоколов ТСР/ІР 
(ІРѵ4), на уровне виртуальной файловой системы (ѴР5) ив файловых системах 
семейства ЕХТР5 (Ехі2, ЕхіЗ, Ехі4); 

• изоляция адресных пространств процессов; 

• регистрация (протоколирование) и аудит событий, реализованные в виде 
централизованной системы с функцией оповещения администратора безопасности о 
попытках несанкционированного доступа; 

• очистка оперативной памяти и освобождаемых областей данных на запоминающих 
устройствах с файловыми системами Ехі2, ЕхіЗ, Ехі4\ 

• регламентный контроль целостности сущностей файловой системы, в том числе 
неизменности исполняемых файлов и соответствия дистрибутива ОССН на основе 
библиотеки ІхЬдозі, в которой реализован алгоритм хеширования ГОСТ Р 34.11-201- 
(«Стрибог») [11]; 

• создание замкнутой программной среды, позволяющей определить для учётной 
записи пользователя индивидуальный перечень ПО, разрешённого для исполнения, с 
возможностью загрузки иерархических цепочек ключей для проверки цифровой 
подписи исполняемых файлов формата Е/.Р, реализованной в соответствии с ГОСТ Р 
34.10-2012 [10]; 

• маркировка документов при выводе их на печать; 

• обеспечение надёжного восстановления ОССН после сбоев; 

• реализация правил управления доступом к внешним запоминающим устройствам; 

• обеспечение доступа к реляционным базам данных; 

• обеспечение доступа к информации через сервер гипертекстовой обработки данных; 

• обеспечение обмена сообщениями электронной почты. 

Основные из перечисленных механизмов защиты детально рассмотрены в главе 3, а 
также в лабораторном практикуме, приведённом в главе 4 настоящего учебного пособия. 

1 . 3 . 3 . Области применения ОССН 

Рассмотренные архитектурные особенности ОССН, включающие поддерживаемые 
сервисы, средства создания масштабируемых отказоустойчивых высокодоступных 
инфраструктур, в том числе и с применением средств виртуализации, а также 



интегрированный в состав ОССН комплекс механизмов защиты определяют основные 
области её применения: 

• автоматизированные системы в защищённом исполнении; 

• программно-технические комплексы и комплексы средств автоматизации; 

• корпоративные сети; 

• территориально-распределенные автоматизированные системы. 

В настоящее время на базе дистрибутива ОССН реализован ряд проектов по 
созданию АС и АСЗИ в министерствах и ведомствах, корпорациях, предприятиях 
промышленности, органах государственной власти субъектов Российской Федерации, в том 
числе: 

• Минобороны России, МВД России, Минобрнауки России; 

• ФСБ России, ФСО России, СВР России, ФСТ России, ФТС России, ФСИН России, 
Росгвардия России; 

• Росатом, Роскосмос, Ростех, Газпром, Роснефть, РЖД; 

• Тамбовская, Челябинская и Свердловская области; 

• Межведомственная информационная система государственной автоматизированной 
системы государственного оборонного заказа (ГАС ГОЗ). 

На рис. 1.15 представлен вариант реализации корпоративной защищённой локальной 
вычислительной сети (ЗЛВС), поддерживающей мультисервисную систему связи (МСС), 
которая обеспечивает реализацию защищённых сервисов: 

• видеоконференцсвязи (ВКС); 

• ІР-телефонии; 

• информационного портала на базе ѴѴеЬ-сервера, 

• сервера баз данных; 

• почтового сервера. 


Рис.15. Вариант реализации корпоративной ЗЛВС для мультисервисной системы связи на 
базе ОССН 




Указанные виды сервисов создаются на базе серверных платформ, которые 
функционируют в серверном варианте развертывания ОССН. 

В качестве клиентских компонент такой ЗЛВС выступают: 

• стационарные и мобильные компьютеры с процессорной архитектурой Іпіеі Х86-64, 
которые функционируют в клиентском варианте установки ОССН релиза «Смоленск»; 

• планшетные компьютеры с процессорной архитектурой АНМ функционирующие в 
клиентском варианте установки ОССН релиза «Новороссийск». 

Для абонентов корпоративной ЗЛВС организуется ЕПП на базе доменных 
инфраструктур АІ-0 или РгееІРА с выделенным контроллером домена, функционирующим в 
серверном варианте развёртывания ОССН, например, релиза «Мурманск». 

Возможности ОССН позволяют организовать многоуровневые масштабируемые 
высоконадежные системы обработки информации обеспечивающие поддержку как контура, 
в котором циркулирует открытая информация, так и контура, в котором обрабатывается 
информация различного уровня конфиденциальности, включая информацию с грифом 
секретности до «совершенно секретно» включительно. Пример организации подобной 
двухконтурной системы обработки информации представлен на рис. 1.16. 

Таким образом, комплект релизов ОССН обеспечивает возможность создания как 
АСЗИ на различных программно-аппаратных платформах, так и различных конфигураций 
защищенных компьютерных сетей, включающих, в том числе облачные технологии и 
механизмы защищенного удаленного доступа. 

Также ОССН все более активно используется в образовательном процессе по 
направлению «Информационная безопасность», так как её механизмы защиты являются 















удобной лабораторной базой для изучения теории и практики по этому направлению, напри¬ 
мер мандатных управления доступом и контроля целостности. Для этого АО «НПО 
РусБИТех» осуществляет безвозмездную передачу ОССН осуществляющим подготовку 
специалистов по защите информации образовательным организациям страны. 
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Рис.1.16. Вариант организации двухконтурной масштабируемой высокодоступной 
системы информации на базе ОССН 
















































































































































1.4. Основы пользовательской работы и администрирования в ОССН 

При включении питания компьютера с установленной на нем оССН после этапа 
процедуры РОЗТ системы ВІ08/ЕРІ отображаем экран начального загрузчика ОИІІ ОНІІВ 2 
Ьооііоасіег (рис. 1.17). По умолчанию ОССН может быть загружена в двух основных режимах: 

• НагсІепесІ — загрузка НагсіепесІ-ОССИ, особенности которого рассмотрены в 
предыдущем разделе; 

• Оепегіс — загрузка базового ядра ОССН. 

В режимах НагсІепесІ и Оепегіс можно выбрать загрузку гесоѵегу тосіе 
(восстановления), в котором выполняется сценарий с проверкой ошибок доступа к корневой 
файловой системе или остановки процесса загрузки из-за ошибок в каком-либо сервисе. При 
этом режим гесоѵегу тосіе предоставляет администратору ОССН (в данном случае 
пользователю от имени учётной записи гооі) интерфейс СИ для запуска утилит диагностики 
и восстановления. Следует помнить, что в случае, когда учётная запись пользователя гооі 
заблоки¬ 



рую. 1.17. Экран загрузчика ОИІІ ОНІІВ 2 
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Рис. 1.18. Предупреждение сценария загрузки гесоѵегу тосіе о невозможности 


доступа к консоли суперпользователя, при блокировке учетной записи гооі 
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Рис. 1.19. Консоль суперпользователя при загрузке в режиме гесоѵегу тосіе 
-рована (в ОССН версии 1.6 это сделано по умолчанию), доступ к консоли гесоѵегу тосіе 
невозможен и загрузка ОССН продолжится в штатном режиме (рис.1.18). В случае 
разблокированной учётной записи гооі суперпользователь получает доступ к СИ интерфейсу 
гесоѵегу тосіе (рис. 1.19.) 


Ввод команды ригпаіеіі с опциямихЬ позволяет выполнить вывод данных из журнала 
системных событий системы инициализации зузіетсі, специфичных для выбранного режима 
загрузки. Анализ этих данных даёт возможность суперпользователю проанализировать 
проблемы с этапами загрузки ОССН. С целью поэкранного просмотра списка сообщений 
рекомендуется использовать конвейер іоигпаіеіі -хЬ |1езз. 

Пример вывода данных из журнала системных событий системы инициализации 
зузіетб (об успешном запуске самой системы журналирования системных событий) 
представлен на рис. 1.20. 

После окончания процесса загрузки в режимах НагбепесІ или Сепегіс пользователю 
предоставляется возможность работы с ОССН в графическом режиме (интерфейс ОШ) или 
в режиме командной строки (интерфейс ОЫ). 

В соответствии со сценарием инициализации системы Ребіап ОІ\ИІ/І_іпих, на базе 
которой разработан дистрибутив ОССН, пользователю по умолчанию предоставляется 
возможность работы: 
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Рис. 1.20. Пример ввода данных из журнала системных событий системы инициализации 


зузіегп 





Интерфейс ОШ 



Доступ к 

графическому экрану, 
клавиатуре и мыши 
и/или сенсорному 




















Рис. 1.21. Последовательность загрузки СИ- и 6/Л-интерфейсов 


• с интерфейсом СИ в шести терминалах — консоли йуІ-й Л 6 (в качестве оболочки по 
умолчанию используется командный интерпретатор ЬазК) 

• с интерфейсом ОІЛ в седьмом терминале — консоль НуІ (в качестве интерфейса ОІЛ 
используется защищённый рабочий стол Ну). 

В общем виде последовательность загрузки СИ- и 0111-интерфейсов представлена 
на рис. 1.21. Переключение между терминалами Ііу1-ііу7 осуществляется комбинацией 
клавиш Сігіч- АН ч-Річ, где N — номер консоли (устройства Ну), в котором пользователь будет 
регистрировать свою сессию. 

В консолях Куі-йуб при входе пользователя в систему ( процесс іодіп) реализован 
диалог ввода значения мандатного уровня 
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Рис. 1.22. СИ-интерфейс пользователя в консоли НуІ 

целостности. По умолчанию допускается ввод значений “Низкий” (числовое значение 0) или 
«Высокий» (числовое значение 63). Вид терминала на примере консоли Пуі представлен на 
рис. 1.22. 

В консоли 11у7 при входе пользователя также реализован диалог выбора атрибутов 
безопасности (в случае отсутствия настроек мандатного управления доступом в диалоге 
возможен только ввод уровня целостности): 

• уровня доступа; 

• неиерархических категорий; 

• уровня целостности; 

Для уровня этих атрибутов загружается ОІІІ-интерфейс представленный начальным 
экраном графического входа в систему (процесс (Іу-дсіт). Его управляющие элементы 
показаны на рис. 1.23. 
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Рис. 1.23. Экран графического входа в систему 
Рассмотрим элементы экрана входа в систему “Тип сессии” и “Меню” подробнее. 

«Тип сессии» элемент управления обеспечивает пользователю выбор среды 
пользовательской сессии ОССН. При этом X предоставляется возможность переключиться 
между следующими режимами сессии: 

• безопасный (графическая сессия с использованием графической версии терминала — 
утилиты ІІу-Іегт)] 

• десктоп (графическая сессия с использованием защищённой графической 
подсистемы Ну) — применяется по умолчанию; 

• мобильный (используется (ЗѴѴ-интерфейс рабочего стола Ну и набор приложений, 
адаптированные для работы с экранами мобильных устройств); 

• планшетный (вариант сессии десктоп, адаптированный для работы с сенсорными 
экранами). 

Безопасный режим предназначен для работы в ОССН с интерфейсом СИ 
(реализуемым после запуска графического сервера Х.Огд утилитой ІІу-Іегт) с 
использованием консольных команд. Часто применяемые консольные команды в утилите Иу- 
іегт заданы в виде выпадающего списка. Выбранная из него команда переносится в 
командную строку, после чего достаточно ввести её аргументы и (при необходимости) опции. 
Также этот список можно изменить с помощью соответствующего элемента меню 
«Настройка» утилиты ііу-іегт. Выход из безопасной сессии выполняется с помощью эле¬ 
мента «Выход» меню «Файл» утилиты (Іу-іегт или командой епі в командной строке. При этом 
в случае, если открыты две или более вкладки виртуальных терминалов потребуется 
подтверждение завершения сессии. 








Мобильный режим предназначен для использования ОССН на мобильных 
устройствах (планшеты, смартфоны), имеющих поддерживаемую ОССН аппаратную 
конфигурацию. Элементы управления рабочего стола Р/у адаптированы под особенности 
подсистемы ввода-вывода этих устройств (сенсорный экран с многопальцевым управлением 
и использованием жестов). В мобильном режиме используется специально адаптированный 
под этот режим набор приложений (рис. 1.24). Не рекомендуется выбирать этот режим при 
эксплуатации ОССН на обычных компьютерах. 

Планшетный режим реализует функциональность режима дес ктоп. Элементы СѴѴ- 
интерфейса в этом режиме адаптированы (Укрупнены) для пальцевого управления ими с 
использованием 
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Рис. 1.24. Состав приложений, адаптированных для работы в мобильном режиме 



Рис. 1.25. Пользовательский интерфейс планшетного режима 

«Меню»» — элемент управления, позволяющий реализовать следующие 


возможности: 

















• сменить пользователя (комбинация клавиш АІ1+І) — отображает список открытых 
пользовательских сессий с указанием: пользовательских учётных записей, номеров 
виртуальных терминалов (ѵі1-ѵі7), на которых они выполняются и типов 
пользовательских сессий (например, ТТУ); 

• перезапуск X сервера (комбинация клавиш АН+Е) — позволяет передать текущему 
сеансу Х.Огд сервера сигнал принудительного перезапуска; 

• виртуальная клавиатура (комбинация клавиш АН + К) — выводит на экран 
регистрации виртуальную клавиатуру. Применяется в случае невозможности 
использования аппаратной клавиатуры на традиционных рабочих станциях или же при 
установке ОССН на устройствах с сенсорным экраном; 

• консольный вход (комбинация клавиш АН+М) — позволяет работать с интерфейсом СИ 
в терминале консоли Нуі. При выборе этого пункта меню пользователю 
предварительно отображается окно с сообщением о том, что переключение в 
консольный режим приведёт к невозможности работы в графическом режиме, который 
станет возможным снова через 10 секунд после окончания последнего успешного 
консольного входа или через 40 секунд, если ни один консольный вход не будет 
осуществлён; 

• выключение (комбинация клавиш АН+8) — выводит на экран окно завершения работы 
с ОССН. Используя это окно, пользователь может произвести выключение или 
перезагрузку ОССН без выполнения входа какого-либо пользователя, а также спла¬ 
нировать выключение/перезагрузку по истечении заданного интервала времени 
(режим планирования доступен только суперпользователю или пользователю с 
правами суперпользователя и требует ввода его пароля). 

Рассмотренные настройки графического входа в систему заданы по умолчанию. 
Однако администратор ОССН имеет возможность изменить их с использованием 
графической утилиты Пу-адтіп- дт, запуск которой можно осуществить двумя способами: 

• с применением элемента «Вход в систему» меню «Настройки» главного меню 
защищённой графической подсистемы Р/у (рис. 1.26); 

• через ввод команды Пу-адтіп-дт в командной строке утилиты Пу-Іегт (рис. 1.27). 




Рис. 1.26. Элемент “Вход в систему” меню “Настройки” 



Рис. 1.27. Интерфейс графической утилиты ііу-асітіп-сіт 
Первый три вкладки меню Лу-асітіп-сіт (“Основное” /'Диалог” и "Тема”) 
предназначены для оформления окна графического входа в систему с использованием 
соответствующих тем. Вкладки “Выключение”, “Пользователи” и “Дополнительно” 
предназначены для конфигурирования работы интерфейса графического входа в систему. 

Для выхода пользователя из сеанса работы и/или завершения работы ОССН 
используется утилита “Выход и выключение” (графическая утилита (Іу-зМиІсІоѵѵп-сІіаІод), 
вызываемая из “Системные” меню “Завершение работы” главного пользовательского меню , 
интерфейс которой приведен на рис. 1.28. 






















Рис. 1.28. Интерфейс графической утилиты выхода из сессии и/или завершения работы 
ОССН 



Рис. 1.29. Интерфейс диалога выбор типа сессии 

Управляющие кнопки интерфейса сгруппированы потрём позициям (рис. 1.29): 

• прерывание работы системы — кнопки «Блокировка», «Сон», «Гибернация»; 

• выход из пользовательской сессии или выключение (перезагрузка) ОССН — кнопки 
«Выход», «Перезагрузка», «Выключение»; 

• планирование выполнения перечисленных функций или смена типа сессии 
пользователя — кнопки «Планирование», «Сессия», «Закрыть». 

• Интерфейс диалога смены типа сессии включает следующие 

• Отдельная — позволяет запустить пользовательскую сессию в новом виртуальном 
терминале. При этом сессия текущего пользователя останется открытой, и в 
дальнейшем к ней можно будет вернуться в любой момент. Запуск новой 
пользовательской сессии возвращает пользователя к экрану входа в систему. При 













вводе данных учетной записи нового пользователя она будет открыта в новом 
виртуальном терминале. При этом в элементе “Меню” экрана входа в систему в 
подпункте “Сменить пользователя” появятся записи открытых пользовательских сессий 
с указанием номеров виртуальных терминалов, на которых они выполняются и типов 
пользовательских сессий (рассмотрены выше). В случае смены пользовательской 
сессии в защищенной графической подсистеме РІу при уже выполняющейся другой 
(других) пользовательской сессии в элементе меню “Тип новой графической сессии” 
появится дополнительный подпункт, указывающий, какой пользователь, на каком 
терминале и какого типа открыл эту сессию. 

• Вложенная позволяет запустить новую пользовательскую, сессию в текущей 
пользовательской сессии РІу в отельной окне менеджера ХОМ (X Оиріау Мападег), 
который является составной частью сервера Х.Огд и позволяет запускать графические 
сессии локально или удалённо. Для взаимодействия с приложениями-клиентами 
менеджер ХОМ использует протокол ХОМСР (ХОМ Сопігоі Ргоіосоі). При этом 
пользовательская сессия запускается локально, и сервер Х.Огд взаимодействует с 
клиентами через ІР-адрес 127.0.0.1 узла Іосаіііозі. Результатом этого является 
появление новой пользовательской сессии в окне менеджера ХОМ. Таким образом, в 
рамках одной пользовательской сессии РІу может функционировать другая поль¬ 
зовательская сессия РІу. 

1.4.2.0сновные приёмы работы с защищённой графической подсистемой РІу 

В графической сессии по умолчанию используется защищённая графическая 
подсистема РІу, при функционировании которой применяются: 

• сервер Х.Огд реализация сервера X ѴѴІпсІоѵѵ Зузіет с открытым исходным кодом; 

• рабочий стол РІу, который, в свою очередь, состоит из менеджера окон РІу ѴѴІпсІоѵѵ 
Мападег (утилита ііу-ѵѵт) и набора графических утилит (Ну- утил) для пользователей и 
администраторов с графическим интерфейсом ОІЛ. 




Рис. 1.30. Элементы интерфейса рабочего стола ІІу 
Менеджер окон Р/у ѴѴІпсІоѵѵ Мападег организует работу графической оконной среды 
ОССН, загружает рабочий стол Р/у и его окружение (заданный набор графических утилит). 
Интегрированный в среду рабочего стола менеджер рабочих столов обеспечивает поддержку 
одновременной работы с несколькими рабочими столами (по умолчанию, с четырьмя). 

Рабочий стол Р/у загружается после регистрации пользователя в графической сессии. 
Он содержит пространство рабочего стола с фоновым изображением, панель задач и 
элементы интерфейса учетной записи пользователя (рис. 1.30). 

Главное пользовательское меню (вызывается при нажатии на экране кнопки «Пуск») 
состоит из каскадно-выпадающих списков доступных пользователю приложений и функции 
(рис.1.30.) По своей функциональности оно максимально приближено к главному 
пользовательскому меню ОС семейства Місгозоі ѴѴІпсІоѵѵз. 

Каждый пользователь ОССН имеет возможность индивидуально настроить рабочий 
стол Р/у (внешний вид, расположение элементов, особенности работы с клавиатурой и 
мышью). Часть таких настроек жестко определяется администратором и недоступна 
непривилегированному пользователю. 

Доступные пользователю настройки могут быть заданы с использованием 
графической утилиты «Панель управления» ( ііу-адтіп-сепіег ) вызываемой последовательно 
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Рис. 1.31. Пример каскадно-выпадающего списка главного пользовательского меню (кнопка 
”Пуск”) 

«Пуск» — «Панель управления» — «Рабочий стол». Эта утилита позволяет 
централизовано использовать некоторые административные и пользовательские 
приложения рабочего стола Ну, которые для удобства разделены на несколько категорий. 
Например, категория «Рабочий стол» объединяет графические утилиты, большинство из 
которых могут быть применены пользователем для настройки своего индивидуального 
рабочего стола. 

Важной особенностью защищённой графической подсистемы Ну является 
интегрированная поддержка механизмов защиты ОССН. По умолчанию пользователю 
доступны следующие ее функции: 

• изменение пароля своей учётной записи с помощью консольной команды раззѵѵб или 
графической утилиты «Политика безопасности»; 

• изменение владельца или группы, владеющей объектом файловой системы (сущности 
в рамках МРОСЛ ДП-модели), созданным пользователем, с помощью консольных 
команд сііоѵѵп и сіідгр, файловых менеджеров МібпідМ Соттапбег и ііу-іт] 

• изменение прав доступа в рамках модели тіпітаі АО. (дискреционное управление 
доступом) к сущности файловой системы 
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Рис. 1.32. Вид индикатора настроек безопасности пользовательской сессии 

• созданной пользователем, с помощью консольной команды сіітосі, файловых 
менеджеров МісІпідМ Соттапсіег и Ну-1т; 

• установка уровней доступа (включая неиерархические категории) и целостности при 
создании новой пользовательской сессии (субъект-сессии в рамках МРОСЛ ДП- 
модели); 

• получение для текущей пользовательской сессии информации о её уровнях доступа и 
целостности с помощью консольной команды рсір-ісі или визуально в области 
уведомлений на панели задач. 

Таким образом, для учётной записи пользователя, для которой администратором 
ОССН установлены несколько допустимых мандатных уровней доступа и целостности, на 
экране графического входа в систему (см. рис. 1.23) отобразится меню установки их конкрет¬ 
ных значений. В дальнейшем выбранные уровни отображаются в виде индикатора в области 
уведомлений на панели задач (рис. 1.32). 

Для большей наглядности при обработке информации конкретным оконным 
приложением с 61//-интерфейсом значение его уровня доступа дублируется цветовым 
кодированием: 

• уровень 0 — голубой; 

• уровень 1 —желтый; 

• уровень 2 — оранжевый; 

• уровень 3 — темно-розовый; 

• уровень 4 — красный; 

• уровень 5 — коричневый; 

• уровень б — пурпурный; 

• уровень 7 — темно-фиолетовый. 

Цветовое кодирование применяется как для индикации значений уровня доступа в 
области уведомлений, так и к рамке, обрамляющей окно приложения. На рис. 1.33 и 1.34 






показан пример цветового кодирования окна файлового менеджера Иу-іт для 
пользовательской сессии со значением уровня доступа равным 1 (желтое цветовое 
кодирование). 



Рис. 1.33. Пример цветового кодирования значения уровня доступа субъект-сессии, 
соответствующей оконному приложению 



Рис. 1.34. Пример цветового кодирования значения мандатного уровня модального окна 
файловой операции 


Как правило, в реальных ОССН этому значению соответствует уровень доступа “Для 
служебного пользования”. 
























Детальное описание теоретических основ реализуемого в ОССН на основе МРОСЛ 
ДП-модели мандатных управления доступов и контроля целостности будет приведено в 
главе 2, а порядок их стройки и администрирования рассмотрен в главе 3. 

1.4.3. Основные задачи администрирования ОССН 

В общем случае процесс администрирования ОС на базе проекта ОеЫап (^N^/^іпиx 
(в том числе ОССН) включает решение следующих основных задач: 

• администрирование учётных записей пользователей и групп с целью организации 
многопользовательской работы ОССН и реализации управлении доступом процессов 
(субъект-сессий, функционирующих от имени учётных записей пользователя) к 
файлам, каталогам и другим объектам доступа ОССН ( сущностям в рамках МРОСЛ 
ДП-модели); 

• администрирование процессов с целью оптимизации распределения между ними 
ресурсов аппаратного обеспечения; 

• администрирование запоминающих и периферийных устройств с целью управления 
доступным их пространством и динамически подключаемыми устройствами. 

В случае включения устройства с ОССН в сетевую среду и его функционирования в 
составе доменной инфраструктуры, перечень задач дополняется администрированием сети 
и доменов, рассмотренным в п. 1.3 и более подробно в главе 3. 

Администрирование учётных записей пользователей и групп. Отправной точкой 
реализации управления доступом в ОССН являлось унаследованное от ОС проекта ОЛ/І// 
Ипих дискреционное управление доступом (РАС — Оізсгеііопагу Ассезз СопігоІ). Поэтому, 
несмотря на то что в настоящее время в ОССН используются мандатные управление 
доступом и контроль целостности, а в перспективе ролевое управление доступом, 
целесообразно рассмотреть основные элементы дискреционного управления доступом, не 
утратившие своей актуальности в современных релизах и версиях ОССН. 

Дискреционное управление доступом в ОС проекта ОЛ/1///_/шх базируется на понятии 
владения (использовании права доступа владения) файлом, каталогом, процессом 
(сущностями и субъект-сессиями). Так, в файловых системах семейства ЕХТР5, в частности 
которая по умолчанию используется в ОССН, с каждым файлом или каталогом связана 
учётная запись пользователя — их владельца (оѵѵпег). Процесс, функционирующий от имени 
такой учетной записи-владельца сущности, имеет право изменять дискреционные права 
доступа к ней, например назначать их учетным других пользователей ОССН на основе 
стандарта Р08ІХ АО. [127]. 

Для оптимизации и облегчения администрирования дискреционного управления 
доступом в случаях, когда к одним и тем же файлам или каталогам требуется установить 
одинаковые права доступа более чем для одной учётной записи пользователя, в ОССН 


применяются группы учётных записей пользователей. В результате для файлов и каталогов 
владельцем (обладателем к ним правом доступа владения) может быть задана группа. При 
этом для них остаются владельцами и соответствующие учетные записи пользователей. В 
перспективе при реализации в ОССН ролевого управления доступом вместо учетных записей 
пользователей и групп владельцами будут задаваться роли или административные роли. 

Таким образом, при управлении доступом в ОССН, в том числе дискреционным, 
администрируют следующие его элементы: 

• учётные записи пользователей (ассоипі); 

• группы (логические объединения учётных записей пользователей с равными 
дискреционными правами доступа); 

• права доступа к файлам, каталогам, другим объектам доступа (сущностям и субъект- 
сессиям); 

• режимы доступа, обеспечивающие возможность учёта ряда особенностей управления 
доступом. 

Утилиты администрирования учётных записей пользователей и групп реализованы в 
пакете ЗЬасІоѵѵ Зиііе [137]. Кроме них для этого используется ряд системных файлов, которые 
конфигурируются администратором системы. Такие файлы в рамках МРОСЛ ДП-модели 
рассматриваются как сущности, параметрически ассоциированные с учётными записями 
пользователей. 

Основой для задания учётных записей пользователей и групп являются их 
идентификаторы: 

• иісі (ІІзег Ю) — число, уникально идентифицирующее учётную запись пользователя в 
ОССН; 

• дісі (Огоир Ю) — число, уникально идентифицирующее группу пользователей ОССН. 

Эти идентификаторы хранятся в следующих конфигурационных файлах, которые 
используются специальным процессом реализующим вход пользователя в ОССН — его 
идентификацию и аутентификацию: 

• /еіс/раззѵѵсі —файл с данными об учётных записях пользователей; 

• /еіс/дгоир — файл с данными об учётных записях групп пользователей. 

Учётная запись каждого пользователя представляет одну строку в файле /еіс/ раззѵѵсі. 
Таким образом, регистрация новой учётной записи пользователя в системе, фактически, 
является добавлением соответствующей строки в этот файл (рис. 1.35). Разделителем полей 
данных в строке учётной записи является символ «:». В результате у администратора есть 
возможность фильтрации требуемых дынных об учетной записи пользователя (например, с 
помощью утилит дгер или сиі). 
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Рис. 1.35. Пример строки, соответствующей учетной записи пользователя асІтіп-16-ІиІІ в 
файле /еіс/раззѵѵсі 

В состав строки, соответствующей учётной записи пользователя, входят поля: 

• изегпате — уникальное символьное имя, присваиваемое каждой учётной записи 
пользователя (при выборе имени могут использоваться буквы и цифры, а также знак 
подчёркивания и точка); 

• иісі — уникальный идентификатор учётной записи пользователя (представлен числом); 

• дісі —уникальный идентификатор первичной группы, в которую входит учётная запись 
пользователя (представлен числом); 

• хеш пароля — может храниться либо непосредственно в рассматриваемой строке (рис. 
1.36), либо, если вместо пароля задан символ <х», то он хранится в системном файле 
/еіс/зііасіоѵѵ, доступном для чтения и записи только суперпользователю или 
пользователю с правами суперпользователя (рис. 1.37); 

• ТиІІ пате — полное имя учётной записи пользователя (например, пользователь с 
изегпате равным зісіог может иметь полное имя «Іѵап 8ісІогоѵ», а также в этом же 
элементе через запятую могут перечисляться дополнительные сведения о поль¬ 
зователе: домашний и рабочий номера телефонов, адрес и т. д.); 

• Ііоте сіігесіогу — домашний каталог учётной записи пользователя, находящийся в 
каталоге /Іюте 1 

• Іодіп зііеіі — командный интерпретатор [зііеіі), который запускается при входе 
пользователя в ОССН, по умолчанию это интерпретатор Ьазіі (/Ып/ЬазЬ). 
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Рис. 1.36. Фрагмент хеша пароля в файле /еіс/раззѵѵсі 
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Рис. 1.37. Фрагмент хеша пароля в файле /еіс/зііасіоѵѵ 
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Рис. 1.38. Диалог команды раззѵѵсі при смене пароля пользователя 
Создание, удаление и изменение учетных записей пользователей осуществляется 
администратором (в рамках МРОСЛ ДП-модели ему соответствует доверенная субъект- 
сессия, обладающая соответствующими текущими специальными административными 
ролями) с использованием следующих приемов: 

• непосредственное редактирование файла /еіс/раззѵѵсі] 

• применение утилит из пакетов раззѵѵсі и асісіизег, 


• активизация из меню “Пользователь” графической утилиты ІІу-асІтіп-зтс (“Управление 
политикой безопасности”). 

В ОССН получение идентификатора учётной записи пользователя (иісі), а также 
других связанных с ним наборов параметров, возможно с помощью команд ѵѵіюаті, ід, ѵѵію. 
Для изменения пароля учётной записи пользователя используется команда раззѵѵсі, которая 
проверяет заданные правила формирования пароля, например его минимальную длину или 
же то, что он создан на основе предыдущего пароля (рис. 1.38). 

Для корректного администрирования учётной записи пользователя (в том числе с 
добавлением при её создании в домашний каталог необходимых конфигурационных файлов) 
администратор может использовать команды асісіизег, изегаМ (создание), изегтосі 
(модификация параметров) и изегсіеі (удаление). В рамках МРОСЛ ДП-модели этим 
командам соответствуют де-юре правила вида сгеа!е_изег, зе!_изег_ІаЬеІз и с!еІеІе_изег. 
Пример использования команды асісіизег приведен на рис. 1.39. 

Как было указано выше, при работе в графической среде, для администрирования 
учетных записей пользователей можно использовать графическую утилиту (“Управление 
политикой безопасности”), доступную из элемента “Панель управления” - “Безопасность” 
главного пользовательского меню (рис. 1.40). 
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Рис. 1.39. Пример использования команды асісіизег 








Рис. 1.40. Главное окно утилиты “Управление политикой безопасности” 
Учётные записи пользователей, зарегистрированных в ОССН локально, 
администрируются из раздела «Пользователи» вкладки «Локальная политика». При этом все 
учётные записи пользователей разделены на два класса: Обычные и Системные (в этот 
класс входят встроенные учётные записи, а также учётные записи прикладных и системных 
сервисов). 



Рис. 1.41. Администрирование параметров учетной записи пользователя 



















Выбрав какую-либо учетную запись администратор ОССН может посмотреть и изменить ее 
параметры, которые считываются из файла /еіс/раззѵѵсі (рис. 1.41). 

Добавление учетной записи пользователя так же осуществляется администратором 
с использованием утилиты “Управление политикой безопасности” (рис. 1.42). 
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Рис. 1.42. Интерфейс меню “Создание пользователя” 

Для безопасности ОССН важна регулярная проверка корректности параметров 
учетных записей пользователей, для чего администратор может использовать команду рѵѵск 
(от раззѵѵогд скеск), которая проверяет целостность данных и правильность формата записи 
в файлах /еіс/раззѵѵсі и /еіс/зкіасіоѵѵ, при этом проверяются: 

• корректность количества полей в записях файлов; 

• уникальность имен учетных записей пользователей; 

• уникальность идентификаторов учетных записей пользователей; 

• корректность принадлежности каждой учетной записи пользователя ее первичной 
группе 

• корректность пути к домашнему каталогу каждой учетной записи пользователя 

• корректность сведений об используемом интерпретаторе по умолчанию. 

Исправление выявленных командой рѵѵск ошибок администратор может осуществить 
с помощью команды изегтосі. 





Данные о каждой группе учетных записей пользователей находится в системном 
файле /еіс/дгоир в строке формата, представленного на рис. 1.43. 

Строка, соответствующая учетной записи группы пользователей, содержит следующие поля: 

• дгоирпате- имя группы; 

• раззѵѵогсі- пароль, установленный для группы; 

• дісі- индетефикатор группы(аналогичный полю дісі в учетной записи пользователя); 

• оікіег тетЬегз- другие пользователи, входящие в состов группы; 

Как и в случае системного файла /еіс/раззѵѵсі, право на запись в файл /еіс/дгоир 
(который является сущностью, параметрически ассоциированной с учетными записями 
доверенных и недоверенных пользователей) 
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Рис. 1.43. Пример строки, соответствующей учетной записи группы асІтіп-16-іиІІ в файле 
/еіс/дгоир 

имеет только администратор, остальные пользователи могут только просматривать его 
содержимое. 

Пользователь может получить данные о своей принадлежности к группам с помощью 
команд /с/и дгоирз. Администратор может создавать, удалять или изменять параметры групп 
учётный записей пользователей: 

• непосредственно редактируя файл /еіс/дгоир', 

• редактируя файлы /еіс/дгоир и /еіс/дзкасіоѵѵ (назначение последнего аналогично 
назначению файла /еіс/зііасіоѵѵ) командой драззѵѵсі; 

• используя команды дгоирасісі и дгоирсіеі ; 

• изменяя параметры групп учетных записей пользователей командой дгоиртосі; 

• использую графическую утилиту “Управление политикой безопасности” (рис. 1.44.). 

Для проверки корректности параметров групп учетных записей пользователей 
используется аналогичная команде рѵѵск команда дгрск, которая анализирует данные файлов 
/еіс/дгоир и /еіс/раззѵѵсі. При этом проверяются: 

• корректность количества полей в записях этих файлов; 





уникальность имен групп; 
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Рис. 1.44. Администрирование групп учетных записей пользователей с использованием 
утилиты “Управление политикой безопасности” 

• уникальность идентификаторов групп; 

• корректность состава учётных записей пользователей и администраторов каждой 
группы. 

Исправление выявленных командой дгрск ошибок администратор может осуществить 
с помощью команды дгоиртод. 

Так как в перспективе на смену группам в ОССН придут роли, запрещающие роли или 
административные роли, то в рамках МРОСЛ ДП-модели командам администрирования 
групп учётных записей пользователей соответствуют де-юре правила вида: 
дгапі_асІтіп_гідЫз, гетоѵе_асІтіп_гідЫз, асІсІ_педаІіѵе_гоІе, гетоѵе_педаНѵе_гоіе, сгеаіе-гоіе, 
сіеіеіе.гоіе сгеаіе _ІіагсІ_Ііпк_гоІе сІеІеіе_ІіагсІ_Ііпк_гоІе, гепате-гоіе, деі_гоІе_аііг 
зе( гоіе ІаЬеІз. 











Администрирование процессов. Администратору ОССН требуется контролировать 
и управлять выполнением совокупности процессов (доверенных или недоверенных субъект- 
сессий в рамках МРОСЛ ДП-модели), которые были запущены пользователями в рамках 
своих сеансов, а также ядром ОССН, системными и прикладными сервисами. 

Основной командой для мониторинга состояния процессов в ОССН является команда 
рз. Запущенная без опций и аргументов, она выводит в терминал список процессов, выпол¬ 
няемых на активном терминале (Ну) или псевдотерминале (різ) (рис. 1.45). При этом для 
каждого процесса указываются: 

• РЮ — идентификатор процесса, который присваивается при его старте из числа 
свободных РЮ в диапазоне значений от О до 2 32 1; 

• ТТУ —терминал (Ну) или псевдотерминал (різ), в котором выполняется процесс; 

• ТІМЕ — время выполнения процесса процессором; 

• СІѴЮ — имя приложения, соответствующего выполняющемуся процессу. 

Использование опций в команде рз позволяет просмотреть более Детальную 
информацию о процессах (пример вывода команды рз с дополнительными опциями приведён 
на рис. 1.46). 

Прототипом команды рз, позволяющим моделировать получение данных о процессах 
(субъект-сессиях), в рамках МРОСЛ ДП- модели является де-юре правило вида 
деІ_зиЬ]есІ_аІІг. 
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Рис. 1.45. Пример ввода команды рз без параметров 
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Рис. 1.46. Пример вывода команды рз с дополнительными опциями 
Команда рзігее дополняет команду рз, с ее помощью можно отобразить дерево 
процессов, функционирующих на всех терминалах, в формате “предок-потомок”. Это 
позволяет проследить цепочку порождения исследуемого процесса и получить возможность 
корректного управления им (особенно это касается его завершения) с учётом его 
«родственных связей». Без параметров команда рзігее выводит дерево процессов, где 
каждый процесс идентифицируется именем соответствующего ему приложения (рис. 1.47). 

Команды рз и рзігее позволяют получить сведения о запущенных процессах, 
отследить их текущее, состояние и взаимосвязи друг с другом. Для того чтобы получать 
данные о процессах, собранные за некоторый интервал времени, используется команда Іор. 
Принцип её работы основан на периодическом анализе обновлений таблицы процессов 
ОССН, что позволяет отследить изменение их параметров (рис. 1.48). 
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Рис. 1.47. Пример ввода команды рзігее 
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Рис. 1.48. Пример ввода команды іор 

Информация, выводимая командой Іор, содержит общие данные о процессах и 


ресурсах ОССН: 


• число пользовательских сеансов (изег); 

• усреднённая загруженность ресурсов системы (Іоас) аѵегаде)-, 

• общее число процессов (іоіаі іазк) и число процессов, находящихся в разных 
состояниях (гиппіпд, зіееріпд, зіорресі и ют- Ые); ’ ; ь г- ... 

• загруженность процессора (%Сри); 

• распределение оперативной памяти между процессами (КіВ Мет); 

• используемые области подкачки страниц (КІВ Зѵѵар). 

Кроме того, команда іор выводит в терминал все данные, выводимые командой рз в 


режиме детализированного вывода. 

При работе в з ащи щённой графической подсистеме Р/у информацию, аналогичную 
выводимой командой іор, можно получить с использованием графической утилиты 
«Системный монитор» меню «Системные» главного меню (рис. 1.49). 

Дополнительно графическая утилита «Системный монитор» может осуществлять 
управление процессами, при этом доступны следующие функции: 

• остановки/возобновления работы процессов; 

• прерывания (для допускающих прерывания процессов); 


• завершения процессов. 






В ОССН администратор может управлять запущенными процессами, передавая им 
сигналы с использованием команды /с/7/ (в Рамках МРОСЛ ДП-модели ей соответствует де- 
юре правило вида с)еІеІе_5е55іоп). 



Рис. 1.49. Пример вывода графической утилиты “Системный монитор” 


Процесс, получив сигнал, может отреагировать на него либо по умолчанию, 
заданному ядром ОССН, либо использовать собственную функцию обработки сигнала. В 
основном сигналы команды /с/7/ предназначены для реализации различных режимов 
прерывания, завершения, приостановления или возобновления работы процессов. Команда 
кіІІаІІ является расширением команды /с/7/ и отличается от неё тем, что посылает сигналы всем 
процессам запущенным при выполнении одного приложения. 

Также администратор и пользователи ОССН имеют возможность влиять (например, 
с помощью команды пісе) на использование выполняющимися процессами ресурса времени 
центрального процессора путем изменения их приоритета, указывающего ядру ОССН, где 
расположить процесс в общей очереди готовых к выполнению на центральном процессоре 
процессов. 

Администрирование устройств ( на примере запоминающих устройств).Для 
упрощения администрирования устройств, несмотря на большое разнообразия 












соответствующего им периферийного оборудования и запоминающих устройств, в ОССН 
заданы всего два их типа: 

• символьные- любые периферийные и запоминающие устройства, обмен данными с 
которыми ведется посимвольно (побайтно). К таким устройствам относятся, например, 
принтер, сканер, мышь, клавиатура, монитор; 

• блочные - периферийные устройства, обмен данными с которыми ведется блоками 
(последовательностями байт), размер которых зависит от устройства. Например, при 
хранении данных на жёстких дисках блоками являются сектора (каждый сектор при 
режиме адресации /_В/\ имеет размер 2048 байт). 

В ОССН устройствам соответствуют файлы специального типа (задание устройств 
файлами позволило не определять для них цельных элементов МРОСЛ ДП-модели, а 
представлять их сущностями), в их индексных дескрипторах (іпосіе), которые можно получить, 
например, с помощью команды ІзІ, используется первый байт:”с” — как обозначение файла 
символьного устройства, “Ь” — как обозначение файла блочного устройства. 

Кроме того, в іпосіе файлов устройств размещается два параметра, используемых 
ядром ОССН для задания драйверов устройства: 

• тарг питЬег — указывает подсистеме ввода-вывода ядра ОССН на драйвер класса 
устройств (например, всех жёстких дисков или всех сетевых карт); 

• тіпог питЬег — указывает подсистеме ввода-вывода ядра ОССН на драйвер 
конкретного устройства. 

На рис. 1.50 показан пример вывода команды ІзІ для файлов устройств /деѵ/зсіа (файл, 
соответствующий интерфейсу контроллера 5С5І) и /сіеѵ/ііуі (файл, соответствующий первому 
виртуальному терминалу). При этом первый файл является блочным устройством (через 
интерфейс 5С5І данные передаются блоками — секторами), а второй файл символьным 
устройством (виртуальная консоль обрабатывает входные данные побайтно). 

Очевидно, что для драйверов файловой системы ОССН и подсистемы безопасности 
РАН5ЕС файлы устройств представляют собой обычные файловые объекты, к которым 
применимы как стандартные вызовы по работе с файлами, так и функции назначения 
Уровней конфиденциальности или целостности. 
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Рис. 1.50. Пример ввода іпосіе файлов устройств /6 еѵ/зсіа и /деѵ/йуі 
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Рис 1.51. Пример использование команды рф-Із-М для вывода уровней 
конфиденциальности файлов устройств /сіеѵ/зсіа и /сІеѵ/НуІ 
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На рис. 1.51 представлен пример вывода команды рф-Із-М (ее функциональность и 
синтаксис будут подробно рассмотрены в главе 3), которая является аналогом команды /з с 
расширенными функциями отображения меток конфиденциальности файлов и каталогов. 
При этом для файлов символьных (файл /сІеѵ/ПуІ) и блочных (файл /сіеѵ/зсіа) устройств могут 
быть назначены уровни конфиденциальности и целостности, а также заданы 
неиерархические категории. Благодаря такому использованию контекста безопасности для 
файлов устройств можно задать правила мандатного управления доступом и контроля 
целостности, как и для других сущностей ОССН. 

Именование файлов запоминающих устройств в большинстве случаев 
стандартизовано для всех версий ОС проекта ОМІІ/Ипих. Важной особенностью ядра ОССН 
является то, что запоминающие устройства с интерфейсами АТА (ЮЕ), 8АТА (е8АТА) и 115В 
подключаются к нему не напрямую, а опосредованно, через драйвер запоминающих 
устройств с интерфейсом 5С5І (рис. 1.52). Связано это с тем, что реализация системы 
команд интерфейса ЗСЗІ существует как поверх интерфейсов АТА/ЗАТА (называется 
АТАРІ — А ТА Раскеі Іпіеііасе), так и поверх протокола 115В (называется МЗР- Мазз Зіогаде 
Оеѵісе). Они позволяют подключать в ОССН любые АТА, ЗАТА и 115В запоминающие 
устройства, не разрабатывая для них собственного протокола обмена, а используя 
имеющийся в системе драйвер интерфейса ЗСЗІ. Такая модификация стека драйверов 
запоминающих устройств была реализована в рамках проекта Р/.055 (Ргее/НЬге Ореп Зоигсе 
ЗоІІѵѵаге) [139] и получила название объединённая подсистема АТА-ЗСЗІ. Согласно этому 
подходу устройствам в каталоге / сіеѵ соответствуют файлы устройств с именем вида зсі , при 
этом если подключены жёсткие диски, имеющие логическую структуру, то в таком имени 
будет цифра. Такое именование файлов устройств соответствует стандарту РОЗІХ. 

Администратор ОССН с использованием параметров устройств (тафг питЬег и тіпог 
питЬег) имеет возможность создавать или модифицировать файлы устройств, 
применительно к конкретному перечню устройств, имеющихся на компьютере. 




Рис. 1.52. Схема реализации стека драйверов запоминающих устройств на основе 
объединенной подсистемы АТА-8СЗІ 








Однако подобный подход является не совсем удобным в современных условиях, 
когда разнообразие типов и число конкретных реализаций устройств существенно возросло. 
Поэтому в версиях ОС проекта ОЛ/І Шпих, начиная с ядра 2.6.т, включая ОССН, начиная с 
версии 1.4 и выше, применяется система динамического именования запоминающих 
устройств исіеѵ, которая использует идентификационную информацию непосредственно 
самих устройств, а не их абстрактные параметры (та]ог питЬег и тіпог питЬег). К такой 
идентификационной информации относится: серийный номер устройства, его положение в 
ЗАТА-интерфейсе или канале РАТА- шины. Сочетание этой идентификационной 
информации устройств (и соответственно, их дисковых разделов) является уникальным, что 
позволяет динамически формировать уникальные имена для каждого устройства. 

Для получения этой идентификационной информации система обращается к зузіз — 
виртуальной файловой системе, экспортирующей на пользовательский уровень из ядра 
ОССН данные о имеющихся в системе устройствах и драйверах. Эти данные могут быть 
получены администратором с помощью графической утилиты Яу-асітіп-сіеѵісе- 
таладег(элемент “Менеджер устройств” меню “Системные” главного меню) (рис. 1.53). 



Рис. 1.53. Пример идентификационной информации о блочном устройстве 
СОРОМ/ОѴОРОМ, отображаемой утилитой “Менеджер устройств” 

Система исіеѵ обеспечивает все необходимые средства для динамического создания 
и удаления файлов устройств и символических ссылок в каталоге / с/е ѵ, её управление 
осуществляется командой исіеѵасіпп. При этом система исіеѵ позволяет администратору 










ОССН изменять порядок её работы, например, путём разработки собственных сценариев 

интерпретатора Ьазк. Благодаря исіеѵ в каталоге /деѵ находятся файлы только тех устройств, 

которые в настоящий момент подключены к системе. Если устройство отключается от 

системы, то файл устройства, связанный с ним, удаляется. 

Функциональные возможности системы исіеѵ реализуются демоном (системным 

процессом, работающим в фоновом режиме без непосредственного взаимодействия с 

пользователем) исіеѵсі, порядок старта которого в ОССН указан в сценарии / еіс/іпіі.сі/исіеѵ 

(рис. 1.54). Дополнительные параметры для этого демона могут быть указаны в 

конфигурационном файле Іеіс/идеѵ/исіеѵ. сопі. 

Каждому устройству в ОССН демон исіеѵсі присваивает уникальный идентификатор 

ІІІІЮ (ІІпіѵегзаІІу ІІпідие ІсІепШіег). Его использование ядром ОССН (драйверами устройств) 

позволяет сделать независимым обработку обращений к устройству от текущих параметров 

его подключения. Это, например, удобно для переносных устройств вида еЗАТА жестких 

дисков, ІІЗВ-дисков, интерфейс подключения которых может меняться. 
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Рис. 1.54. Пример сценария инициализации демона исіеѵсі 


/йеѵ/зйаі : 1ШО= ,, ЗГа47601-Ь38а-4йе6-95йМ18й8с1522523 , ‘ ТУРЕ="ех14 м РЮ?ТШЛ0= 
"3702е3с8-0і" 

/йеѵ/зйаб: ^^I^=‘‘йе50йа^Ь-7Ьс9-4951-Ье01-57Нс!2*Ь5с7е■ , ТУРЕ="зыар" РВРТииіО= 
"3702еЗс8-05" 


Рис. 1.55. Пример ввода команды ЫкісІ 

Для получения используемых системой исіеѵ идентификаторов и параметров 
блочных устройств администратор может использовать команду ЫкісІ, которая без 
параметров выведет данные файла /еІс/ЫкісІ.ІаЬ (рис. 1.55), обновляющегося при каждой 
загрузке ОССН. 







В ходе динамического именования устройств система исіеѵ также может выполнять 
ряд дополнительных действий, которые могут быть описаны в виде правил системы исіеѵ 
(исіеѵ гиіез), хранящихся в файлах с расширением .гиіез в каталоге /еіс/исіеѵ/гиіез.сі. При этом 
одному устройству может соответствовать больше одного правила, что позволяет задавать 
для каждого устройства разные альтернативные имена, а также определять разные 
дополнительные действия, ассоциированные с этими именами. Система идеѵ, обнаружив 
соответствующий устройству файл правил, будет продолжать просматривать каталог / 
еіс/исіеѵ/гиіез, с/ в поисках других файлов правил, в которых указан ІІІІЮ этого устройства. 

Благодаря возможности автоматического формирования файлов правил системой 
исіеѵ подсистема безопасности РАР5ЕС в ОССН реализует следующие дополнительные 
функции по работе с устройством: 

• регистрация устройств в локальной базе учета (в случае автономной рабочей станции) 
или базе учета, хранящейся в базе учета контроллера домена /\/_0 (в случае клиента 
домена /4/.0); 

• управление доступом к зарегистрированным устройствам на основе политики 
безопасности, основанной на уровне их конфиденциальности и целостности. 
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Рис. 1.56. Пример формата секции база учета устройств подсистемы безопасности РАР5ЕС 
(на примере регистрации ІІЗВ-носителя) 

В случае локально* регистрации устройств база учёта создаётся в конфигурационном 
файле еіс/ рагзес/ сіеѵісез, с!д. Для каждого зарегистрированных устройств формируется 
отдельная секция ограниченная блоком вида “{...}” (рис. 1.56). 

Наряду с идентификационными данными устройства соответствующая ему секция 
содержит данные о дискреционных правах доступа к нему, а также о его мандатных уровнях 
конфиденциальности и целостности. Задание последних выполняется с использованием 
графической утилиты «Управление политикой безопасности» Іу-асігтп-зтс) в разделе 
«Устройства и правила» (рис. 1.57). 




На основе данных из базы учёта устройств подсистема безопасности РАРЗЕС 
автоматически генерирует файлы правил системы иаеъ, соответствующие учтённым 
устройствам, в состав которых народу с базовыми соответствиями {таісііез) и действиями 
{ асііопз ) добавлено соответствие ЕМѴ{Ю_ЗЕРІАЦ, включающее действия 01/1/Л/ЕЯ, (ЗРОІІР 
и МАО. АВЕІ-, связанные с управлением доступом к устройству. Пример формата такого 
правила следующий: 

ЕЛ/1/^ Ю_ЗЕРІАЦ == ”Оепегіс_ ІІЗВ_ ЕІазЬ_ йізк_00000000000135-0:0”, 

0 1/1/Л/ЕЯ= ”изег-зегѵег-14”, СРОіІР=”изег”МАСІАВЕІ=”1:0г-хг-х” 


Поскольку в процессе учёта устройства его идентификатор ІІІІЮ ассоциируется с 
идентификационными данными учётной записи пользователя, для блочных устройств, 
требующих выполнения операции монтирования имеющихся на них файловых систем, в 
ОССН используется модификация стандартной утилиты тоипі допускающей выполнение 
монтирования не только процессам от имени учетной записи администратора системы, но и 
от имени непривилегированного пользователя, зарегистрированного в текущем сеансе. 



Рис. 1.57. Раздел управления доступом к зарегистрированному устройству 

При этом точкой монтирования файловой системы будет соответствующий каталог в 
каталоге / гип/изег/ %иід%/тесііа данного пользователя, для которой будут применяться 
соответствующие уровни конфиденциальности и целостности, заданные ключом тасІаЬеІ в 
секции, соответствующей устройству в базе учёта (в файле деѵісез, сід). 























Для обеспечения такого способа монтирования файловых систем в 
конфигурационном файле /еіс/ШаЬ включены соответствующие записи с ключами оѵѵпег и 
дгоир для следующих видов блочных устройств: 

• учтённые съёмные устройства для локально зарегистрированных учётных записей 
пользователей; 

• учтённые съёмные устройства для учётных записей пользователей домена АІО; 

• файловые системы РА732, Л/7Р5 и ЕХТЕ5, расположенные в разделах учтённых 
несъемных блочных устройств; 

• Файловые системы ІЮЕ и 1809660, расположенные на учтённых оптических дисках. 

Примером записи в файле /еІс/ШаЬ для учтённых съёмных устройств локально 
зарегистрированных пользователей является следующая запись: 

/сіеѵ/з */Іюте/*/тесІіа/*аиІо оѵѵпег, дгоир, поаиіо, поехес, іосЬагзеІ=иШ, деіаиііз 0 0. 

Таким образом, управление доступом к устройствам в ОССН может осуществляться 
способами традиционными для ОС семейства І_іпих и с применением возможностей 
реализованных в ОССН мандатного управления доступом и контроля целостности. 



Контрольные вопросы 

1. С чем связана потребность в разработке отечественных защищенных ОС? Какие к ним 
предъявляются требования? 

2. По профилю защиты ОС общего назначения ( типа А) какого класса сертифицирована 
ОССН? 

3. Какие процессорные архитектуры поддерживают релизы ОССН версии 1.6? 

4. Что означает факт принадлежности дистрибутива ОССН к РеЬіап Регіѵаііѵез? 

5. С помощью какой консольной команды можно получить информацию о текущей версии 
релиза и имени релиза ОССН? 

6. На пакетной базе какого релиза ОССН реализован релиз с кодовым именем 
“Новоросийск”? 

7. Какова область применения ОССН? 

8. Как реализована в ОССН подсистема безопасности РАНЗЕС, и какие функции она 
обеспечивает? 

9. Какие дополнительные защитные функции реализованы в усиленном (НагсІепесІ) 
варианте ядра ОССН? 

10. В чем состоят основные функциональные отличия между технологиями формирования 
доменной архитектуры, поддерживаемыми ОССН? 

11. Какие модули ядра в составе ОССН релиза 1.6 относятся к невыгружаемым? 

12. В каком терминале (устройство Ну*) в ОССН по умолчанию реализуется доступ к 
защищённому рабочему столу Р/у? 

13. Какая библиотека подсистемы защищённого рабочего стола Р/у не зависит от 
библиотек платформы 015 и является решением разработчика ОССН? 

14.14 Какую функцию в составе подсистемы защищённого рабочего стола РІу реализует 
библиотека ІІЬрагзес-тас-р15-І? 

15. Какие компоненты входят в состав технологического стека виртуализации, 
реализованного в ОССН релиза 1.6? 

16. Какие протоколы доступа к удалённому рабочему столу гостевого домена 
используются в стеке виртуализации ОССН релиза 1.6? 

17. На основе каких компонентов реализован отказоустойчивый кластер ОССН релиза 
1 . 6 ? 

18. Каково назначение сервиса кеераііѵесі для организации кластера на базе ОССН релиза 
1 . 6 ? 

19. Каково назначение файловой системы СерН в состав ОССН релиза 1.6? 



20. В чем разница между вложенной и отдельной пользовательскими сессиями? 

21 .Какие права имеет администратор по управлению учетными записями пользователей 
и групп пользователей? 

22. С какой целью для учетной записи пользователя ОССН определяются первичная и 
вторичная группы, и с какими правилами МРОСЛ ДП-модели можно ассоциировать их 
администрирование? 

23. Чему в МОРСЛ ДП-модели соответствует наследственное в ОССН от ОС семейства 
І_іпих дискреционное управление доступом? 

24. С помощью какого механизма в ОССН пользователь имеет возможность управлять 
состояниями и приоритетом выполнения процессов? Существуют ли в МОРСЛ ДП- 
модели правила, соответствующие такому механизму? 

25. Какой интерфейс по умолчанию используется для подключения ІІ8В-устройств? 
Почему в ОССН не реализовано непосредственное использование этого интерфейса? 

26. Как в ОСН реализовано управление доступом к подключаемым устройствам? 

27. В чем сходство, а в чем отличия пользовательской работы и администрирования 
ОССН от типичных для ОС семейства І_іпих? 



2 Мандатная сущностно-ролевая ДП-модель управления доступом и 
информационными потоками в операционных системах семейства Ыпих 


2.1 Подход к формированию модели в ее иерархическом представлении 

Традиционно механизм управления доступом рассматривается как основа 
обеспечения безопасности компьютерных систем, в особенности защищённых ОС с 
мандатным управлением доступом. Для научного исследования свойств этого механизма за 
более чем 40 лет построены десятки теоретических моделей [17, 105]. Однако большинство 
отечественных разработчиков защищённых ОС используют (как правило, только формально) 
для реализации механизма управления доступом устаревшие, неадекватные условиям 
функционирования современных ОС модели (например, классическую модель Белла- 
ЛаПадулы [17, 103], ролевые модели семейства ВВАС [17, 133, 134]), что не позволяет 
повысить доверие к безопасности этого механизма. 

При этом для современных защищённых ОС актуальна разработка формальной 
модели, обеспечивающей возможность сочетания востребованного в них мандатного 
управления доступом с перспективным ролевым управлением доступом. «Механическое» 
объединение этих двух видов управления доступом без учёта специфики каждого из них 
может негативно отразиться на безопасности полученного решения, в том числе при 
обеспечении защиты от запрещённых информационных потоков по памяти или по времени. 
Например, запрещённые информационные потоки по времени от сущностей с высоким 
уровнем конфиденциальности к сущностям с низким уровнем конфиденциальности 
(“аналогичные рассмотренным в [15]) назначения и субъектами с использованием 
назначения и отзыва в согласованные моменты времени прав доступа ролей. 

Изложенный в [17, 134] подход к созданию на основе ВВАС мандатного ролевого 
управления доступом не может быть эффективно реализован в реальных защищенных ОС, 
так как для противодействия запрещенным информационным потокам по памяти он 
предполагает возможность разделения всех ролей по уровням конфиденциальности 
сущностей, права доступа к которым они предоставляют, и по видам доступа к ним роли-«на 
чтение» и роли-«на запись», с применением соответствующих ограничений на функции 
текущих ролей сессий (субъектов) и прав доступа ролей. При этом не рассматриваются 
механизмы защиты от запрещённых информационных потоков по времени и невозможно (без 
использования в дополнение ролевому дискреционного управления доступом) задание 
индивидуальных прав доступа пользователей. 

Рассматриваемая в пособии мандатная сущностно-ролевая ДП- модель управления 
доступом и информационными потоками в операционных системах семейства Ыпих (МРОСЛ 



ДП-модель) является результатом применения апробированных на классических моделях 
[17, 105] и семействе ДП-моделей [14, 17] подходов к теоретическому анализу безопасности 
управления доступом и информационными потоками и адаптации моделей к условиям 
функционирования современных компьютерных систем. Модель впервые [16, 20, 76] 
обеспечивает сочетание мандатного управления доступом, мандатного контроля 
целостности и ролевого управления доступом, позволяющее через представление ролей 
сущностями-контейнерами (элементами виртуальной файловой системы ОССН) обеспечить 
возможность противодействия созданию нарушителем с использованием параметров ролей 
запрещённых информационных потоков по времени «сверху-вниз» (от сущностей с высоким 
уровнем конфиденциальности к сущностям с низким уровнем конфиденциальности). При 
этом нацеленность модели на реализацию в ОССН позволила сфокусировать её разработку 
на формировании комплексного научно обоснованного технического решения [18], 
заключается в следующем: 

• включение в модель элементов типичных для ОС семейства І_іпих, в особенности для 
механизмов защиты ОССН; 

• строгое доказательство существенных для практического применения ОССН условий 
её безопасности в первую очередь безопасности мандатного и ролевого управления доступа 
и мандатного контроля целостности (в том числе безопасности информационных потоков по 
памяти и по времени), 

• обеспечение возможности с использованием методик верификации кода программ с 
применением инструментов дедуктивного доказательства Носііп РІаНогт (Еѵепі-В), Егата-С 
(ѴѴІіуЗ) [19, 93,94,110,114] осуществить вывод и формальное обоснование корректности 
самой модели, а также корректности ее реализации непосредственно в программном коде 
ОССН. 

Ряд элементов модели, например ролевое управление доступом, еще не 
используются в ОССН. Эти элементы включены в модель для создания условий для 
разработки будущих версий ОССН на основе изначально прошедших через теоретический 
анализ технических решений. 

Несмотря на достаточно детальную проработку в МРОСЛ ДП-модели порядка 
функционирования механизма мандатного и ролевого управления доступом и мандатного 
контроля целостности ОССН, модель продолжает своё развитие, становясь, с одной сто¬ 
роны, «ближе» к ОССН, с другой стороны, позволяя строго теоретически обосновывать в 
рамках модели новые проверяемые на практике условия безопасности ОССН. Таким 
образом, представленное в настоящем пособии описание модели имеет ряд существенных 
отличий от изложенного в [17] и в первом (втором) издании настоящего учебного пособия [4]. 



Так, в [17, 4] описание МРОСЛ ДП-модели являлось «монолитным», т. е. элементы 
модели давались в порядке, принятом в классических моделях, который удобен при 
относительно небольшом объёме описания модели. В начале такого описания приводились 
элементы состояний задаваемой в рамках модели абстрактной системы, далее описывались 
требования к реализации в системе мандатного и ролевого управления доступом и 
мандатного контроля целостности, затем давались правила преобразования состояний 
системы, и з заключение формулировались и обосновывались условия безопасности 
системы. В результате модель в её «монолитном» описании стало все труднее 
корректировать, так как каждое изменение в каком- либо её элементе требовало учёта во 
всех других связанных с ним элементах модели, а также проверки справедливости 
большинства обоснованных в модели утверждений. Кроме того, из-за большого объёма и 
«монолитности» модели, невозможности в таком виде её поэтапной реализации 
затруднялось использование модели разработчиками ОССН, а также создание на её основе 
новых моделей (например, модели гипервизора или СУБД). 

Все перечисленное стало причиной переработки МРОСЛ ДП- модели в её 
иерархическое представление. Первоначально при его разработке в модель (по сравнению 
с её «монолитным» представлением) не добавлялись новые элементы, а основной целью 
являлось формирование следующих четырех упорядоченных уровней [21]: 

• первый уровень (базовый) модель системы ролевого управления доступом; 

• второй уровень модель системы ролевого управления доступом и мандатного 
контроля целостности 

• третий уровень модель системы ролевого управления доступом, мандатного контроля 
целостности и мандатного управления доступом только с информационными потоками по 
памяти 

• четвертый уровень модель системы ролевого управления доступом, мандатного 
контроля целостности и мандатного управления доступом с информационными потоками по 
памяти и по времени. 

Каждый нижний уровень иерархического представления модели соответствует 
абстрактной системе, элементы которой не зависят от новых элементов, принадлежащих 
более высокому уровню модели, который, в свою очередь, наследует, а при необходимости 
корректирует или дополняет элементы нижнего уровня. Такой подход позволяет постепенно 
усложнять формулировки определений и утверждений модели по мере включения в неё 
соответствующих очередному рассматриваемому уровню элементов. 

Следующим шагом стало включение в иерархическое представление МРОСА ДП- 
модели новых уровней, содержащих элементы, до этого не использованные в «монолитном» 
представлении. 



Во-первых, практика использования МРОСА ДП-модели при реализации ОССН 
показала, что в ряде случаев применение ролей, обладающих только правами доступа к 
сущностям, разрешающим субъектам получение соответствующих доступов к ним, является 
недостаточным и создаёт неудобство при администрировании ОССН. В (79) описываются 
ситуации, когда, например, только одну учётную запись пользователя системы необходимо 
лишить права доступа, предоставляемого ей через роль, которой обладают все учётные 
записи пользователей системы, при этом все другие права доступа этой роли должны быть 
оставлены без изменений. В связи с этим в иерархическое представление модели был 
добавлен уровень запрещающих ролей [23]. Запрещающие роли, в отличие от «обычных» 
ролей, содержат права доступа к сущностям или субъектам, которые не разрешают, а 
наоборот, запрещают получение соответствующих доступов. Этот уровень основан на уровне 
ролевого управления доступом модели, на нем не реализовано мандатное управление 
доступом и мандатный контроль целостности, а для задания запрещающих ролей 
используется описанный еще в ролевых моделях семейства ИВАС механизм ограничений 
(сопзігаіпі). 

Во-вторых, изначально в МРОСЛ ДП-модели для задания мандатного контроля 
целостности применялись всего два уровня целостности: высокий (ЦпідН) и низкий (Моѵѵ). 
Этого было вполне достаточно для разделения всех элементов ОССН на системные 
(доверенные компоненты ОССН, обеспечивающие функционирование процессов её ядра и 
системных процессов, в том числе механизмов защиты и администрирования), обладающие 
высоким уровнем целостности, и пользовательские (недоверенные компоненты ОССН, 
выполняющие функции процессов непривилегированных пользователей, в том числе 
нарушителей), обладающие низким уровнем целостности. Именно в таком виде мандатный 
контроль целостности реализован в версиях 1.4 и 1.5 ОССН. Но при использовании в ОССН 
технологий виртуализации (гипервизора), например, на основе программного комплекса 
средств виртуализации «Брест» [53], а также при реализации сетевой доменной архитектуры, 
требуются дополнительные уровни целостности. Например, одним из возможных решений 
здесь может быть использование трёх уровней целостности: высокого, соответствующего 
системному для основной ОССН, среднего, соответствующего системному для ОССН, 
запущенной в среде виртуализации (виртуализированной), и низкому — пользовательскому 
для основной и виртуализированной ОССН. Кроме того, в перспективе уровней целостности 
может потребоваться больше, в том числе для реализации невырожденной (состоящей из 
более чем двух уровней, где не каждый уровень сравним с каждым) решётки уровней 
целостности. В связи с изложенным был разработан уровень мандатного контроля 
целостности с невырожденной решёткой уровней целостности [22]. 



В-третьих, наиболее интересным стало формирование уровня ролевого управления 
доступом с запрещающими ролями и мандатного контроля целостности с невырожденной 
решёткой уровней целостности МРОСЛ ДП-модели, основанном не на одном, а впервые на 
двух предшествующих уровнях. В результате было показано, что структура иерархического 
представления модели может развиваться не только «древовидно». Она позволяет после 
разработки уровня, содержащие существенные новые элементы, далее дополнить этими 
элементами существующие «верхние» уровни модели, ориентированные на мандатное 
управление доступом с контролем информационных потомков по памяти и по времени. 
Именно это было осуществлено далее при создании уровней ролевого управления доступом 
с запрещающими ролями, мандатного контроля целостности с невырожденной решеткой 
уровней целостности и мандатного управления доступом с информационными потоками по 
памяти, по памяти и по времени. 

В-четвёртых, было осуществлено формирование уровней предназначеных для 
моделирования единого механизма управления доступом ОССН и СУБД РозідгеЗОЦ2А\, 
аналогично включающих уровни ролевого управления доступом, мандатного контроля 
целостности, мандатного управления доступом с информационными потоками по памяти и 
по времени. 

Однако такое ветвление и усложнение структуры иерархического представления 
МРОСЛ ДП-модели, включающее более 10 уровней, в том числе ориентированных на СУБД 
РозІдгеЗОі, показало, что без оптимизации этой структуры дальнейшее развитие модели 
будет затруднено. Причём такая оптимизация фактически следовала из практики внедрения 
модели в ОССН. Например, с инженерной точки зрения добавление запрещающих ролей при 
реализации в ОССН ролевого управления доступом не составляет особой трудности, а после 
начала применения в ОССН версии 1.6 невырожденной решётки уровней целостности 
наличие в модели отдельного уровня всего для двух уровней целостности утратило смысл. 

В связи с этим ряд уровней МРОСЛ ДП-модели были объединены, в результате их 
структура стала соответствовать изначально использованной, состоящей из перечисленных 
ранее четырёх уровней (рис. 2.1). При этом «параллельно» в этой структуре сформированы 
уровни для СУБД РозІдгеЗОі и рассматривается возможность добавления уровней для 
моделирования механизма управления доступом гипервизора. 

Поскольку полное описание МРОСЛ ДП-модели имеет значительный объем, в 
настоящем учебном пособии детально приводится только уровень ролевого управления 
доступом (первый уровень) этой математической модели (в отличие от (33) этот уровень 
включает запрещающие роли). Однако используемая при этом последовательность 
изложения содержания уровня полностью соответствует применяемым для всех 


последующих уровней иерархического представления модели, которые в силу большого 
объема их описание приводится фрагментарно. 

Структура описания уровня ролевого управления доступом иерархического 
представления МРОСЛ ДП-модели состоит из четырех частей, следующих далее. Сначала 
определяются структуры данных, составляющие модель, в первую очередь необходимые 
для описания элементов состояний рассматриваемой в рамках модели абстрактной системы. 
Затем приводятся ограничения на связи между элементами разных видов 
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Г’ис. 2-1. Актуальная структура иерархического представления МРОСЛ 
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регламентируются условия корректности состояний системы, а также переходов системы из 
состояния в состояние. Далее описываются правила перехода системы из состояния в 
состояние, которые соответствуют выполнению тех или иных действий в механизме 
управления доступом ОССН, инициированные непривилегированными пользователями 
администраторами безопасности, а также функционирующими от их имени процессами В 
заключение формулируется утверждение о корректности правил перехода системы из 
состояния в состояние, т.е. выполнения при их применении условий корректности состояний 
системы и самих переходов из состояния в состояние. После описания уровня ролево- 4 
управления доступом приводятся описания основных элементов последующих трёх уровней. 
При этом даются пояснения возможных способов или особенностей их реализации в ОССН. 

2.2 Уровень ролевого управления доступом 

2.2.1 Элементы состояния системы 


































Рассмотрим уровень ролевого управления доступом иерархического представления 
МРОСА ДП-модели. Сделаем следующее предположение (предложения в рамках 
формальной модели описывают на неформальном языке её базовые свойства, что 
обеспечивает её лучшее понимание; они формулируются по ходу описания модели, 
реализуются формально в элементах модели и используются в доказательствах 
утверждений и теорем). 

Предположение 2.1. В рамках МРОСЛ ДП-модели пользователям соответствуют их 
учётные записи. 

Дадим следующие определения и используем обозначения: 

ІІ — конечное непустое множество учётных записей пользователей; 

5 — конечное непустое множество субъект-сессий учётных записей пользователей 
(всех «активных» компонент защищённой ОССН); 

изег: $> ІІ — функция принадлежности субъект-сессии учётной записи пользователя, 
задающая для каждой субъект-сессии учётную запись пользователя, от имени которой она 
активизирована; 

Е = О II С — конечное непустое множество сущностей (всех «пассивных» компонент 
защищённой ОССН, к которым назначаются права доступа), где О — множество объектов 
(например, файлов), С— множество контейнеров (например, каталогов) и О & С =0 . 

Также определим: 

А//ШЕ5 — множество допустимых имён сущностей, ролей, запрещающих и 
административных ролей; 

епШу-пате: С х Е> 2 ЫАМЕЗ Функция имён сущностей в составе сущностей-контейнеров. 
При этом для любых контейнеров с, с’е С, по определению выполняются условия: 

• I епіііу _пате(с, с<)| < 1; 

• если сФ с’ и существует с" е С такой, что епіііу_пате{с,с")Ф0, то епіііу _пате(с, с”') = 0 

• существует единственная сущность- «корневой контейнер» НООТ е С такая, что 
епіііу_пате(с, НООТ) = 0 и, если сФ НООТ, то существует единственная последовательность 
контейнеров сі=с,С 2 ...,с п = РООТ е С такая, что п>2 и епіііу_пате(Сі,Сі-1 )Ф&, где 1 < і < п. 
Определение 2.1. Иерархией сущности называется заданное на множество сущностей Е 
бинарное отношение “ < ”, удовлетворяющее условию: для двух сущностей е,е’ е Е 
выполняются отношения е^е’, когда либо е=е’, либо существует последовательность 
сущностей е1=е,е2,...,е п Ф е’ е Е такая, что п>2 и епіііу_пате(е\,е\-'\)Ф0, где 1<і<п. В случае, 
когда для двух сущностей еі,ег е Е выполняется условие еі^ег и еі^ег, будем говорить, что 
сущность еі содержится в сущности-контейнере ег, и будем использовать обозначение еі<ег. 
Определим функцию иерархии сущностей Не: Е-> 2 е , где для е е Е выполняется НЕ(е)={е’ е Е: 
епШу_пате(е,е’) Ф0}. 


Определение 2.2. Иерархией субъект-сессий называется заданное на множестве 3 
отношение частичного порядка «<», удовлетворяющее условию: если для субъект-сессии з е 
3 существую субъект-сессии зі, зг е 5 такие, что з < 52, з <зі, то зі< 52 ила 52^ зі. В случае, 
когда для двух субъект-сессий зі, 52 е 5 выполняются условия зі< 52 и зі^ 52, будем говорить, 
что субъект- сессия зі является потомком 52, и будем использовать обозначение зі< 52. 
Определим Н 3 :5>2 3 — функцию иерархии субъект-сессий (сопоставляющую каждой субъект- 
сессии з е 5 множество субъект-сессий Нз(з) е 5, непосредственно в ней содержащихся 
удовлетворяющую условиям: 

• если субъект-сессия зі е Н 3 (32), то зі < 52 и не существует субъект-сессии 5 е 5 такой, 
что зі < 5 < зг; 

• для любых субъект-сессий зі 52 е 5, зі Ф 52, выполняется равенство Н 3 (зі) & Н 3 {32) = 0. 

В рамках МРОСЛ ДП-модели иерархия сущностей задана не «абстрактной» функцией 
Н Е , а реализуемой явно в ОССН функцией имён сущностей в составе сущностей-контейнеров 
епИ1у_пате что позволит в дальнейшем описать правила предоставления содержимого 
контейнеров (например, списков файлов и каталогов, выдаваемых в ОССН по команде Із) с 
учётом параметров мандатного управления доступом. При этом учтено наличие механизма 
создания “жестких” ссылок (кіагсі Ііпк) в файловой системе ОССН, обеспечивающего 
возможность размещения сущностей-объектов одновременно в нескольких сущностях- 
контейнерах, в том числе несколько “жестких” ссылок на одну сущность-объект в составе 
одной сущности-контейнера. Также исключается возможность наличия у сущности- 
контейнера двух имен (двух “жестких” ссылок) в составе другой сущности-контейнера, а также 
описаны свойства корневой сущности-контейнера ВООТ, как правило, соответствующей в 
ОССН корневому каталогу 7”. 

По сравнению с предыдущими ДП-моделями определено, что множество субъектов- 
сессий не входит во множество сущностей. Это связно с тем, что в ОССН функции 
управления доступом к субъект- сессиям (процессам) и сущностям (файлам, каталогам) 
реализуются раздельно. Таким образом, иерархия на множестве субъект-сессий 
определяется независимо от иерархии сущностей и при реализации в ОССН может быть 
задана двумя способами. Первый способ, когда существует явная связь между 
родительскими субъект-сессиями и их потомками (например, когда при завершении работы 
родительской субъект-сессии завершают работу её субъект-сессии потомки, подчинённые 
родительской в иерархии). Второй способ, когда порождённая субъект-сессией другая 
субъект-сессия функционирует независимо, в этом случае подчинение её в иерархии 
родительской субъект-сессии нецелесообразно. 

Используем следующие обозначения: 

В — множество ролей; 



ЫВ — множество запрещающих ролей, при этом по определению В & N14 = 0; 

АВ — множество административных ролей, при этом по определению АВ & МВ = АВ 
& В = 0 (административные роли — особый вид ролей, предназначенный для изменения 
множеств прав доступа ролей и запрещающих ролей, авторизации на роли, а также 
выполнения функций по администрированию системы); 

8АВ с АВ — множество специальных административных ролей, которые не могут 
создаваться, удаляться, переименовываться, менять свои параметры в процессе 
функционирования системы; 

В г = {геесіг, ѵѵгііег, ехесиіег, оѵѵп г ) множество видов прав доступа; 

В а = {геасіа, ѵѵгііеа} множество видов доступа; 

Рс (Е х Вг) II (8 х {оѵѵпг} множество прав доступа к сущностям и субъект-сессиям; 

АР с (В ІІ ЫВ ІІ АВ) х Вг множество административных прав доступа к ролям, 
запрещающим ролям или административным ролям; 

А_с 8 х Е х В а - множество доступов субъект-сессий к сущностям; 

АА с 8 х (В ІІ ЫВЯ АВ) х В а - множество доступов субъект-сессий к ролям, 
запрещающим ролям или административным ролям; 

РА: Я ІІ Л/Я ёМЯ—► 2 Р функция прав доступа к сущности ролей запрещающих ролей 
и административных ролей, при этом для каждого права доступа р е Р существует роль г е В 
1/ЫВ ІІ АВ такая, что выполняется условие р е РА(г); 

АРА: АР —► 2 АР — функция административных прав доступа к ролям, запрещающим 
ролям и административным ролям административных ролей, при этом для каждого 
административного права доступа ар е АР существует административная роль аге АВ такая, 
что выполняется условие ар е АРА(аг): 

8Ьатесі_сопіаіпет:. С II Я II Л/Я II АР —> {ігие, іаізе } — функция разделяемых 
контейнеров такая, что сущность-контейнер, роль, запрещающая роль или административная 
роль с е СII ЯII Л/Я II АР я вляется разделяемой, когда зііагесІ_сопіаіпег(с) = ігие, в противном 
случае зііагесІ_сопіаіпег(с) = іаізе; 

V: Е ІІ Я ІІ /ѴЯ I) АР-> {(а.,... ,а п ): аі е {0,1}, 1 < і < т п > 1} II {0} — функция значений 
сущностей, ролей, запрещающих ролей и адми нистративных ролей (как аналогов сущностей- 
контейнеров), задающая возможность для каждой из них принимать значение любой (в том 
числе пустой) конечной последовательности битов; 

гоіе-пате: (Р ІІ Л/Я ІІ АР) * (В ІІ Л/Я.ШЯ} —> Л/АМЕ5 — функция имён ролей, 
запрещающих ролей и административных ролей в составе роли, запрещающей роли или 
административной роли (как контейнера). При этом для любых ролей, запрещающих ролей 
или административных ролей г, г' е В ЕІ Л/Я и АР, по определению выполняются условия: 

• \гоІе.пате(г, г)/<\\ 



• если гоІе.пате( г, г') Ф 0, то либо г, г' е В, либо г, г' е ЫВ. либо г, г' е АВ; 

• для роли, запрещающей роли или административной роли г” е В ІІ ЫВ ІІ АВ 
справедливо гоІе-пате{ г, г") = гоІе-пате{ г’,г”); 

• если существует последовательность ролей, запрещающих ролей или 
административных ролей п =г,Г 2 ,...,г п =г’е В (УЫВ ІІ АН такая, что п > 2 и гоІе.пате{ п,гм)^0, 
где 1< і < п, то не существует последовательности ролей, запрещающих ролей или 
административных ролей г’і=г’,г’ 2 ,...,г’ т = г еВ ё/І\ІП ІІ АВ такой, что т>2 и гоІе.пате[ г’і, г'м) 
Ф0, где 1< і < т: 

Поскольку традиционно в ОССН рассматриваются три вида прав доступа к сущностям: 
на чтение, на запись и на выполнение (или на использование контейнера каталога)а так же 
при дискреционном управлении доступом к сущностям и субъект-сессиям учитывается 
наличие у каждой из них уникального владельца, имебщего право передавать права доступа 
к ним другим учётным записям пользователей, то в рамках МРОСЛ ДП-модели будем 
использовать виды прав доступа геасі,., ѵѵгііег, ехесиіег, оѵѵп г , и виды доступов геасіа,, и \л/ті*е а 

Определение 2.3. Иерархией ролей, запрещающих ролей или административных 
ролей называется заданное на множестве ролей В, Л/Я или АН соответственно бинарное 
отношение «<», удовлетворяющее условию: для ролей, запрещающих ролей или 
административных ролей г, г' е В II МН ІІ АН выполняется отношение г < г', когда либо г = г', 
либо существует последовательность ролей, запрещающих ролей или административных 
ролей п=г,Г 2 , ..., Гп = г' е В ІІ Л/Я ІІ АН такая, что п >2 и гоІе_пате{ г\,г\-\)Ф0, где 1 < і < п. В 
случае, когда для двух ролей, запрещающих ролей или административных ролей п, гг е Я II 
N Я II АН выполняются условия п < гг и п Ф Г 2 , будем говорить, что роль, запрещающая роль 
или административная роль п содержится в роли, запрещающей роли или административной 
роли гг, и будем использовать обозначение п < гг. Определим функцию иерархии ролей, 
запрещающих ролей или административных ролей Нв:Я II Л/Я II АН —> 2 В II 2 МВ II 2 АЯ , где для 
ге Н ІІ Л/Я ІІ АН выполняется Ни (г) = {г’ Е Я ІІ Л/Я ІІ АН / гоІе_пате(гі г') Ф0]. 

В отличие от других формальных моделей управления доступом, впервые 
предлагается считать роли, запрещающие или административные роли аналогом сущностей- 
контейнеров, к которым субъект-сессии могут иметь (через административные роли) права 
доступа и получать доступы. При этом в рамках МРОСЛ ДП- модели иерархии ролей, 
запрещающих ролей и административных ролей заданы (по аналогии с иерархией 
сущностей) не функцией Нв а функцией имён ролей в составе ролей-контейнеров гоІе_пате. 
Таким образом, право доступа оѵѵпг, — владелец роли, геасТ - право получать роль как 
текущую, просматривать её параметры, ѵѵгііег, право изменять множество прав доступа роли, 
ехесиіег, — право обращаться к ролям, подчинённым данной роли в иерархии ролей (по 
умолчанию предполагается, что такое право доступа к ролям имеется всегда); доступ геасіа 


получение субъект—сессией роли как текущей, доступа ѵѵгііеа- изменение прав доступа роли 
или состава ролей подчиненных ей в иерархии. 

Имеющиеся в ОССН привилегии целесообразно задать административными или 
“обычными” ролями, это обеспечит целостность механизма управления доступом в ОССН, и, 
кроме того, позволит в дальнейшем присваивать ролям-привилегиям уровни 
конфиденциальности и уровни целостности. 

В результате закладывается основа единого механизма мандатного управления 
доступом и мандатного контроля цнлостности для доступов к сущностям, получения в 
качестве текущих и администрирования ролей субъект-сессиями, с возможностью 
противодействия В дальнейшем запрещённым информационным потокам по памяти или по 
времени. 

Кроме того, для сущностей-контейнеров, ролей, запрещающих ролей и 
административных ролей задана функция разделяемых контейнеров (помечаемых в ОССН 
атрибутом «I») и функция их значений. При реализации иерархий ролей в ОССН по аналогии 
с файловой системой можно использовать виртуальную структур, сущностей-ролей, 
отличающуюся от структур для файлов наличием «жёстких» ссылок не только на роли- 
«объекты» (роли, которым в иерархии не подчинена ни одна другая роль), но и на роли- 
«контейнеры» (роли, которым в иерархии подчинена хотя бы одна роль). 

В моделях семейства ВВАС и других ролевых ДП-моделях предполагалось, что 
функция авторизованных ролей учётных записей пользователей ІІА обладает свойством 
«наследования» подчинённых ролей, т. е. выполняется следующее условие: для учетной 
записи пользователя и е I), если роли г, г’, е В такие, что г е І)А(и) и г’ < г, то выполняется 
условие г'е ІІА(и). Это обеспечивается «наследованием» административной ролью права 
доступ- геасіг от данной роли ко всем подчинённым ей ролям в иерархии. При этом права 
доступа ѵѵгтіет и оѵѵп г таким свойством не обладают, что может позволить гибко задавать 
«диапазоны» администрируемых ролей по аналогии с моделью ролевого администрирования 
АВВАС {17,134}. 

Ранее в моделях семейства ВВАС и ролевых ДП-моделях для задания текущих ролей 
использовалась функция гоіез, а для администрирования ролей функции вида сап_аззідп, 
сап_геѵоке и сап_тападе_гідИІз, которые потребовали бы отдельной реализации в 
защищенной ОССН. В МРОСЛ ДП-модели для этого используется контролируемые системой 
мандатного управления доступом (на последующих уровнях модели) доступы субъект-сессий 
к ролям (задаются множество АА) и административные права доступа административных 
ролей (задаются функцией АРА). При этом для обеспечения большего быстродействия 
ОССН при проверке прав доступа субъект-сессий к сущностям целесообразно для каждой 



субъект-сессии хранить списки (по аналогии со списком привилегий) текущих ролей, к 
которым она имеет соответственно, доступы геасіа или ѵѵгііеа. 

Для обеспечения применения запрещающих ролей {79} по аналогии с моделью ВВАС 
{17,134} зададим механизм ограничений (СопзЕгаіпЕз) необходимого обладания 
запрещающей ролью с помощью следующей функции: 

сопзігаіп^н: Я ІІ АП —> 2 т функция необходимого обладания запрещающей ролью, 
задающая для каждой роли или административной роли множество запрещающих ролей, 
которые должна иметь субъект-сессия как текущие в случае обладания ею как текущей 
соответствующей ролью или административной ролью 

Определение 2.4. Пусть определены множества учётных записей пользователей ІІ , 
сущностей Е, субъект-сессий 5, прав доступа к сущностям Р, доступов субъект-сессий к 
сущностям А, доступов субъект-сессий к ролям, запрещающим ролям и административным 
ролям АА, функции административных прав доступа к ролям административных ролей АРА, 
прав доступа ролей РА, принадлежности субъект-сессий учётным записям пользователей 
изег, иерархии ролей Нп, иерархии сущностей Не, иерархии субъект- сессий Нз. Определим 
С = (АРА, РА, изег, А, АА, Нв,Не,Нз, сопзігаіпімв) — состояние системы. 

Данное определение необходимо для теоретического описания состояний 
з ащи щённой ОССН в рамках МРОСЛ ДП-модели и не требует непосредственной реализации 
в ОССН. Используем обозначения: 

І(0*,ОР)-система, при этом: 

• О*- множество всех возможных состояний; 

• ОР- множество правил преобразования состояний, заданных в табл. 2.1 (см. разд. 
2.2.3); 

• Субъект-сессии не могут иметь друг к другу никаких доступов: для субъект-сессий з,з’б 
3 выполняется {(з,5’,а а ): а а 6 Р а }& А=0 

Условие 2 (административные права доступа и иерархия ролей, запрещающих ролей 
или административных ролей): 

• все роли, запрещающие роли и административные роли являются “разделяемыми 
контейнерами”: для каждой роли, запрещающей роли или административной роли г е В II І\ІВ 
II АВ справедливо равенство зІіагесІ_соп1аіпег(г)={гие т , 

• у каждой административной роли есть права доступа егесиівг ко всем ролям, 
запрещающим ролям и административным ролям: для каждой административной роли аг е 
АР, роли, запрещающей роли или административной роли г е Я. \^NН\^ АН выполняется 
условие (г, ехесиіег) е АРА(аг). 



Условие 3 (доступы и права доступа, право доступа владения, администрирование 
параметров, прав доступа сущностей, ролей, запрещающих ролей, административных 
ролей); 

• к ролям, запрещающим ролям, административным ролям и сущностям субъект-сессии 
могут иметь любые виды доступа из множества Н а -, 

• роли, запрещающие роли и административные роли могут иметь к сущностям любые 
права доступа из множества Н г , только административные роли могут иметь к ролям, 
запрещающим ролям или административным ролям административные права доступа из 
множества Н г ; 

• для управления доступом к сущности субъект-сессия должна иметь к ней через 
соответствующую текущую роль или административную роль право доступа владения и не 
должна иметь текущую запрещающую роль, обладающую правом доступа владения к этой 
сущности; 

• для каждой сущности или субъект-сессии, если существует, то единственная роль или 
административная роль, обладающая к ней правом доступа владения, при этом для 
изменения роли или административной роли, обладающей правом доступа владения к 
сущности или субъект-сессии, необходимо наличие у субъект-сессии доступа на чтение к 
административной роли еп1іііез_адтіп_гоІе или зиЬіесІз_ас1тіп_гоІе соответственно: для 
каждой сущности е е Е выполняется условие |{г 6 В II АВ:(е, оѵѵп г ) Е РА(г)}|<1, для каждой 
субъект-сессии з Е 5 выполняется условие |{г Е В II АВ: (з, оѵѵпг) Е РА(г)}|<1, где 
епШіез_асІтіп_гоІе, зиЬіесіз_асІтіп_гоІе е ЗАВ; 

• для каждой роли существует единственная административная роль гоіез _ асітіп _ гоіе, 

обладающая к ней правом доступа владения, для каждой запрещающей роли существует 
единственная административная роль педаІіѵе_гоІез_асІтіп_гоІе, обладающая к ней правом 
доступа владения, для каждой административной роли существует единственная 

административная роль асітіп _ гоіез _ гоіе, обладающая к ней правом доступа владения: для 

каждой роли г Е В выполняется условие {аг’ еАВ:(пг, оѵѵпг) е 

АРА(аг’)}={асІтіп_гоІе5_асІтіп_гоІе}. 

• для управления доступом к роли, запрещающей роли или административной роли 
субъект-сессия должна иметь доступ на чтение к административной роли гоІез_асІтіп_гоІе, 
педаіше_гоІез_ асІтіп_гоІе или асІтіп_гоІез-асІтіп_гоІе соответственно. 

Условие 4 (доступ к сущностям в иерархии сущностей). Для получения субъект- 
сессией любого доступа к сущности, создания «жёсткой» ссылки на неё, получения или 
изменения параметров, прав доступа к ней, активизации из неё субъект-сессии требуется 
существование последовательности непосредственно вложенных друг в друга сущностей- 
контейнеров, начинающейся с некоторой сущности-«корневой контейнер» (например, 



корневой контейнер «/» в ОССН) и заканчивающейся сущностью-контейнером, в состав ко¬ 
торой непосредственно входит сама сущность, и наличие у субъект-сессии текущих ролей 
или административных ролей, обладающих в совокупности правами доступа ехесиіе г ко всем 
сущностям-контейнерам этой последовательности, а также отсутствие у субъект-сессии 
запрещающей роли, обладающей правом доступа ехесиіег хотя бы к одной сущности- 
контейнеру этой последовательности: для состояний системы С и <3’, правила 
преобразования состояний системы ор е ОР таких, что С\- 0 рС’, если субъект-сессия з е 3 
сущность е е Е, (з, е, а а ) € А и (з,е,а а ) е А’, где а а е В а , то существует контейнер с е С и 
ехесиІе_сопіаіпег(з, с , е) =ігие 

Условие 5 (создание, переименование или удаление сущности, роли, запрещающей 
роли или административной роли, или “жесткой» ссылки на неё, получение её параметров): 

• для создания, переименования или удаления сущности, роли, запрещающей роли или 
административной роли или “жесткой” ссылки на нее в сущности-контейнере, роли, 
запрещающей роли или административной роли соответственно, субъект-сессии 
необходимо иметь к последней доступ на запись и текущую роль или административную 
роль, обладающую к последней правом доступа на выполнение ехесиіег, 

• при создании, переименовании или удалении сущности или «жесткой» ссылки на нее в 
сущности-контейнере субъект-сессия не должна иметь текущую запрещающую роль, 
обладающую правом доступа на выполнение к этой сущности-контейнеру; 

• для изменения прав доступа роли, запрещающей роли или административной роли 
субъект-сессии необходимо иметь к ней доступ на запись, за исключением случаев, когда 
либо административным ролям назначаются административные права доступа геасі, или 
ехесиіе, к ролям, запрещающим ролям или административным ролям при изменении их 
иерархии, либо удаляются сущности, субъект-сессии, роли, запрещающие роли или 
административные роли, и, соответственно, удаляются имеющиеся к ним у ролей, 
запрещающих ролей или административных ролей права доступа; 

• для переименования, удаления сущности или «жёсткой» ссылки на сущность е в 
сущности-контейнере с (е е Не (с)), помеченной как разделяемая (зІіагесІ_сопІаіпег(с) = ігие), 
требуется наличие у субъект-сессии доступа на чтение к роли или административной роли, 
обладающей правом доступа владения оѵѵп, к сущности е, и отсутствие у субъект-сессии, 
текущей запрещав щей роли, обладающей этим правом доступа к этой сущности; 

• сущности-контейнеры при создании помечаются как неразделяемые. Для изменения 
метки разделяемое™ сущности-контейнера субъект-сессии необходимо либо обладать 
текущей ролью или административной ролью, имеющей право доступа владения к этой 
сущности-контейнеру, не обладать текущей запрещающей ролью, имеющей право доступа 


владения к этой сущности-контейнеру, либо обладать административным доступом на 
чтение к административной роли епІШез_ас!тіп_гоІе т , 

• для получения субъект-сессии данных о ролях, запрещающих ролях или 

административных ролях, обладающих правами доступа к сущности, требуется либо наличие 
у субъект-сессии роли или административной роли, обладающей правом доступа владения 
оі/илгк этой сущности, отсутствие текущей запрещающей роли, обладающей правом доступа 
владения к этой сущности, либо доступа на чтение к административной роли 
епііііез_асІтіп_гоІе ; 

• для получения субъект-сессии данных о ролях, запрещающих ролях или 

административных ролях, обладающих правом доступа владения к другой субъект-сессии 
или имеющихся у этой субъект-сессии текущих ролях, запрещающих ролях или 

административных ролях, требуется либо наличие у первой субъект-сессии доступа к роли 
или административной роли, обладающей правом доступа владения оѵѵгігко второй субъект- 
сессии, отсутствие текущей запрещающей роли, обладающей правом доступа владения ко 
второй субъект-сессии, либо доступа на чтение к административной роли зиЦесІз.асітіп.гоіе; 

• для создания, переименования, удаления, получения параметров роли, запрещающей 
роли или административной роли, «жёсткой» ссылки на неё, числа «жёстких» ссылок к ней, 
множества административных ролей, обладающих к ней правами доступа, требуется наличие 
у субъект-сессии доступа на чтение к административной роли гоіез.асітіп.гоіе, 
педаііѵе.гоіез.асі- тіп.гоіе или асітіп.гоіез.асітіп.гоіе соответственно: 

Условие 6 (администрирование учетных записей пользователей): 

• для создания или удаления учётной записи пользователя требуется наличие у субъект- 
сессии доступа на чтение к административным ролям изегз.асітіп.гоіе, 
педаііѵе.гоіез.асітіп.гоіее 5АН, доступов на чтение, а при создании и на запись, к адми¬ 
нистративным ролям гоіез.асітіп.гоіе и асітіп.гоіез.асітіп.гоіе, при этом множество субъект- 
сессий, функционирующих от имени данной учётной записи пользователя, должно быть пус¬ 
тым; 

• для получения субъект-сессией параметров учётной записи пользователя она либо 
должна функционировать от её имени, и о иметь текущую административную роль 
изег_.асітіп_гоІе. 

Условие 7 (создание и удаление субъект-сессий). 

• Субъект-сессия может активизировать из сущности новую субъект-сессию от имени 
некоторой учётной записи пользователя только при наличии к сущности права доступа на 
выполнение у хотя бы одной из ролей, к которой активизирующая субъект-сессия имеет 
доступ на чтение, и отсутствии у нее текущей запрещающей роли, обладающей правом 
доступа на выполнение к этой сущности; 



• Субъект-сессия может удалить субъект-сессию, только обладая текущей ролью или 
административной ролью, имеющей к ней право доступа владения, и не обладая текущей 
запрещающей ролью, имеющей право доступа владения ко второй субъект-сессии. 

Условие 8 (вид метки): 

• для каждой сущности, роли, запрещающей роли или административной роли задаётся 
вид её метки: прямая или косвенная, который не изменяется в процессе функционирования 
системы задаётся функция дігесі Е^Ри Л/Я^ АР —> {ігие, іаізе}, где для е еЕ II ЯII Л/Я и АР, 
если сіігесі{е) = ігие, то метка прямая, иначе косвенная; 

• метка каждой роли, запрещающей роли или административной роли является прямой: 
для г еР II Л/Р II АР верно равенство дігесіог) = ігие; 

• если у некоторой сущности-контейнера метка косвенная, то у всех сущностей ниже её 
в иерархии она также косвенная: если для сущности-контейнера с е С выполняется сіігесі(е-) 
іаізе, то для всех сущностей е е Е таких, что е < с, выполняется сіігесі(е) = іаізе; 

• для каждой сущности с косвенной меткой существует единственная старшая её в 
иерархии сущность-контейнер с прямой меткой, для которой все сущности, находящиеся 
ниже её в иерархии имеют косвенные метки, а права доступа всех ролей, запрещающих 
ролей или административных ролей к ним равны правам доступа к этой сущности- 
контейнеру: для каждой сущности е е Е такой, что сІігесІ(е)=ІаІ5е, существует единственная 
сущность-контейнер с е С такая, что сІігесІ(с)=Ігие, е<с и для любой сущности е’е Е такой, что 
е’<с, верно сІігесІ(е’)=ІаІ5е и выполняется (е’,а г ) е РА(г) тогда и только тогда , когда (с, а г ) е 
РА(г); 

• в сущностях-контейнерах с косвенной сеткой нельзя создавать сущности с прямой 
меткой или “жесткие” ссылки на них. В сущности-контейнере с прямой меткой могут 
создаваться сущности или “жесткие” ссылки на них с метками одного вида. “Жесткая” ссылка 
на сущность-объект с косвенной меткой может создаваться в сущности-контейнере, 
подчиненной в иерархии той же самой единственной сущности-контейнеру, которой 
подчинена в иерархии сама сущность-объект. 

Условие 9 (индивидуальная административная и индивидуальная роли учетной 
записи пользователя, общая роль): 

• для каждой учётной записи пользователя и е ІІ задаётся индивидуальная 
административная роль и_асІтіп е АП, не находящаяся в иерархии других ролей, при этом 
задано множество всех индивидуальных административных ролей Ь(_АОМ/Л/ = {и_ас!тіп. и е 
ІІ}. Множество других ролей учётной записи пользователя и задаётся с использованием 
административных прав доступа этой административной роли, определяемых функцией АРА. 
На траекториях функционирования системы у этой административной роли не изменяется 


имя; 


• для каждой учётной записи пользователя задаётся индивидуальная роль, не 

находящаяся в иерархии других ролей, административными правами доступа на чтение, 
запись и выполнение к которой обладает её индивидуальная административная роль: для 
каждой учётной записи пользователя и е ІІ задаётся роль и_с е В такая, что (и_с, а г ) е 
АРА(и_асІтіп), где а г е {теасІг,ѵѵгі1ег, ехесиівг], при этом задано множество всех 
индивидуальных ролей ІІ.ПОІ-Е5 = {іі _с: иеіі}; 

• задаётся общая роль соттоп.гоіе е Я, не находящаяся в иерархии других ролей, 
административными правами доступа на чтение, запись и выполнение к которой обладают 
все индивидуальные административные роли всех учётных записей пользователей, и задано 
множество СОММОN-ПО^Е5 ={соттоп.гоІе}: для каждой учётной записи пользователя и в ІІ 
выполняется (соттоп-гоіе, а г ) е АРА(и-асІтіп), где а г е {геасіг, тііе Т , ехесиІе г }; 

• административные роли гоІез-асІтіп_гоІе и асІтіп.гоІез-Сі.сІ- тіп.гоіе не используются 
для нарушения правил назначения административных прав доступа к индивидуальным 
административным ролям, индивидуальным ролям учётных записей пользователей и общим 
ролям. 

Условие 10 (администрирование функции необходимого обладания запрещающей 
ролью, получение её значения, доступы и права доступа запрещающих ролей): 

• для специальных административных ролей из множества 5 АР не задаются 
запрещающие роли: для аг е 8АР верно сопзігаіпіыя(аг) = & 

• Для изменения значения функции необходимого обладания запрещающей ролью 
сопзігаіпім я субъект-сессия должна иметь административный доступ на чтение к 
административной роли педаііѵе_гоІез_асІтіп_гоІе, а также в зависимости от того, является 
параметр функции ролью или административной ролью, субъект-сессия должна иметь 
административный доступ на чтение к административной роли гоІез_асІтіп_гоІе или 
асІтіп_гоІез_асІтіп_гоІе соответственно; 

• При добавлении для некоторой роли или административной роли запрещающих ролей 
ни одна субъект-сессия не должна иметь к такой роли или административной роли 
административных доступов; 

• для получения субъект-сессией запрещающих ролей, заданных с помощью функции 
сопзігаіп^н для роли или административной роли, или, наоборот, ролей или 
административных ролей, для которых задана запрещающая роль, субъект-сессия должна 
иметь административный доступ на чтение к административной роли 
педа ііѵе_ гоІез_а сІтіп_ гоІе : 

• в случае, когда для некоторой роли или административной роли задано непустое 
множество запрещающих ролей, то административный доступ на чтение субъект-сессии к 
такой роли или административной роли предоставляется только при получении ею 



административного доступа на чтение ко всем соответствующим запрещающим ролям: если 
существуют субъект-сессия з е 5 роль или административная роль г е В I) АП, запрещающая 
роль пг е N14 такие, что пг е сопзігаіпімн (г), (з, г, геасіа) е АА, то (з, пг, геасіа) е АА. 

Условие 11 (доступы субъект-сессии к индивидуальным ролям и общим ролям, 
запрещающим ролям, соответствующим индивидуальным административным ролям, 
индивидуальным ролям или общим ролям): 

• при создании каждой субъект-сессии она получает доступ на чтение к индивидуальной 
административной роли и доступ на чтение и запись к индивидуальной роли ее учетной 
записи пользователя и общей роли: для субъект-сессии з е 3 выполняются условия (з’ 
изег(з)_асІтіп, геасіа), (з, изег(з)_с, геасіа), (з, соттоп_гоІе, геасІ а ), (з, изег(з)_с, тііе а ), (з, 
соттоп_гоІе, тііе а ) е АА; 

• при создании каждой субъект-сессии индивидуальная роль ее учетной записи 
пользователя получает право доступа владения к этой субъект-сессии: для субъект-сессии з 
6 3 выполняется условие (з, оѵѵп г ) е РА(изег(з)_с); 

• если для индивидуальной административной роли или индивидуальной роли учетной 
записи пользователя заданы запрещающие роли, то индивидуальная административная 
роль должна обладать административными правами доступа на чтение ко всем таким 
запрещающим ролям, и при создании от имени этой учетной записи пользователя субъект- 
сессии она получает доступ на чтение ко всем соответствующим запрещающим ролям: если 
для учетной записи пользователя ііеіі выполняется пг Е сопзІгаіпІш(и_асІтіп) II 
соп5ІгаіпІырі(и_с), (пцгеабг) е АРА(и_абтіп); если для субъект-сессии зеЗ верно пг е 
соп5ІгаіпІмв(и5ег(5)_абтіп)ІІ соп51гатЬт(изег(5)_с); 

• если для общей роли заданы запрещающие роли, то индивидуальная 
административная роль каждой учётной записи пользователя должна обладать 
административными правами доступа на чтение ко всем таким запрещающим ролям, и при 
создании любой субъект-сессии она получает доступ на чтение ко всем соответствующим 
запрещающим ролям: если выполняется пг Е сопзІгаіпІмв(соттоп_гоІе), то для всехучётных 
записей пользователей и Е ІІ верно (пг, теад г ) Е АРА(и_асІтіп), и для всех субъект-сессий з Е 
5 таких, что (з, соттоп _гоІе, геасі,.) е е А А, верно (з, пг, геасІ а ) еАА; 

• при удалении субъект-сессии удаляются все её административные доступы к 
индивидуальной, индивидуальной административной и общей ролям. 

Рассмотрим особенности реализации в ОССН условий предположения 2.2. 

В условии 1, в отличие от других ДП-моделей, предполагается, что субъект-сессии не 
могут иметь доступов друг к другу, что соответствует условиям функционирования ОССН. 
При реализации условия потребуется уточнить, что предоставляет право доступа владения 



к субъект-сессии, например даёт ли такое право возможность её отладки или возможность 
выполнить от её имени какое-либо действие в системе. 

Условие 2 обеспечивает потенциальную возможность получения доступа к роли вне 
зависимости от ее положения в иерархии ролей. Кроме того, оно не позволяет субъект- 
сессии, не обладающей соответствующими административными ролями, изменить иерархию 
ролей. Получая доступ на запись к некоторой роли (дающий возможность изменять 
множество ее прав доступа), такая субъективная-сессия не может удалить роли, 
подчиненные данной роли в иерархии, так как она помечена как “разделяемый контейнер”. 

Условие 3 задает общий порядок получения доступов и назначения прав доступа 
ролей, запрещающих ролей или административных ролей, ролей-“владельцев” к сущностям, 
субъект-сессиям, ролям, запрещающим ролям или административным ролям, при этом 
вводятся специальные административные роли епіШез_асІтіп_гоІе, зиЬ]есіз_асІтіп_гоІе, 
гоІез_асІтт_гоІе, педаііі>е_гоІез_адтіп_гоІе и асІтіп_гоІез_асІтіп_гоІе, используемые для 
администрирования сущностей, субъект-сессий, ролей, запрещающих ролей или адми¬ 
нистративных ролей соответственно. 

Условия 4 и 5 задают порядок получения доступа к сущностям, их создания, 
переименования или удаления, получения параметров типичный для ОС семейства Ипих, 
при этом эти условия основаны на ролевом управлении доступом и использовании функции 
ехесиіе_сопІаіпег, при определении которой учитывается требование отсутствия даже одной 
текущей запрещающей роли, обладающей правом доступа на выполнение к сущности- 
контейнеру, через которую соответствующая субъект-сессия делает попытку получить какой- 
либо доступ к сущности. Кроме того, в условиях раскрывается содержание ограничений, 
которые накладываются правами доступа («запрещающими» правами доступа) 
запрещающих ролей при попытке осуществления субъект-сессиями соответствующих досту¬ 
пов к сущностям. 

В условии 6 указываются роли, требуемые для администрирования учётных записей 
пользователей, что в предшествующих ДП-моделях не допускалось. Типичные для ОССН 
условия создания или удаления субъект-сессий заданы в условии 7, в которых учтены 
«запрещающие» права доступа запрещающих ролей. 

Для обеспечения возможности задания в ОССН прав доступа к сущностям, 
находящимся в архивах или на внешних устройствах (файловая система которых часто не 
позволяет хранить права доступа или другие параметры механизма управления доступом, 
например уровни конфиденциальности или целостности, в соответствии с требованиями 
последующих уровней МРОСЛ ДП-модели). в условии 8 используются косвенные метки 
сущностей, с помощью которых указывается, что права доступа ролей, запрещающих ролей 
или административных ролей к сущности (в дальнейшем уровни конфиденциальности или 



целостности) наследуется от сущности-контейнера, являющейся “точкой монтирования” к 
файловой системе архива или внешнего устройства. Так как файловая система ОССН не 
позволяет создавать “жесткие” ссылки на сущности между файловыми системами различных 
устройств, то в соответствии с условием 2 такая “точка монтирования” определяется 
однозначно для каждой сущности с косвенной меткой, а следовательно, однозначно 
задаются права доступа к ней. 

В условии 9, в отличие от моделей семейства ВВАС и других ролевых ДП-моделей, 
вместо функций ІІА и АІІА для задания авторизированных ролей и административных ролей 
учетных записей пользователей используются права доступа их индивидуальных 
административных ролей, задаваемых функцией АРА. Такой подход позволяет реализовать 
ролевое управление доступом назначен прав доступа учётным записям пользователей 
только через роли. Также достигается большая совместимость со штатными механизмами 
управления доступом ОССН. Для обеспечения возможности функционирования в ОССН 
субъект-сессии (процессу) необходимо предоставить хотя бы одну индивидуальную роль, 
обладающую ила имеющую возможность получения прав доступа к сущностям (особенно при 
их создании), «принадлежащим» только учётной записи пользователя, от имени которой 
функционирует субъект-сессия. Например, такие сущности могут располагаться в 
«домашнем» каталоге (/Ііоте/изег}. Кроме того, для предоставления прав доступа ролей, 
которые в дискреционных ОС семейства Ипих задаются «для всех остальных» учётных 
записей пользователей, аналогично индивидуальным ролям учётных записей пользователей 
используется общая роль. На уровне ролевого управления доступом модели она 
единственная, на последующих уровнях модели их может быть несколько, поэтому для 
общих ролей задано соответствующее множество СОММО/Ѵ-ЯО/_Е$.Таким образом, с 
использованием индивидуальных административных и индивидуальных ролей учётных 
записей пользователей и общей роли легко выразить традиционный для ОС семейства Ипих 
подход к реализации дискреционного управления доступом. 

Условие 10 определяет порядок администрирования функции необходимого 
обладания запрещающей ролью сопзігаіп^п а также получения значений этой функции. При 
этом указывается на отсутствие запрещающих ролей, соответствующих специальным 
административным ролям, так как обратное маловероятно потребуется в ОССН и может 
сильно затруднить её администрирование. Также описывается порядок использования 
функции сопзігаіпіып , заключающийся в обязательном получении субъект-сессий 
запрещающей роли как текущей в случае, когда эта субъект-сессия запрещающей роли как 
текущей в случае, когда эта субъект-сессия получает как текущую соответствующую роль или 
административную роль. 



Выполнение условия 11 обеспечивает возможность получения субъект-сессий 
заданной запрещающей роли так текущей, в случае если эта роль соответствует 
индивидуальной роли или индивидуальной административной роли учетной записи 
пользователя этой субъект-сессии. Правом доступа на чтение к такой запрещающей роли 
должна обладать индивидуальная административная роль учетной записи пользователя. В 
этом случае при создании субъект-сессии она сразу получает соответствующую 
запрещающую роль. Аналогично в случае, когда запрещающая роль задана для общей роли, 
то правом доступа на чтение к запрещающей роли должны обладать все учётные записи 
пользователей. Таким образом, условие обеспечивает согласованность задания значений 
функции необходимого обладания запрещающей ролью сопзігаіпімя с правами доступа 
индивидуальных административных ролей учётных записей пользователей. Кроме того, 
условие не указывает, какой административной роли должно быть дано право доступа на 
чтение к запрещающей роли, заданной для какой-то роли или административной роли. Это 
означает, что для того, чтобы получить эту роль или административную роль как текущую, 
субъект-сессии необходимо иметь право доступа на чтение к запрещающей роли через 
индивидуальную административную роль учётной записи пользователя субъект-сессии или 
через любую другую административную роль, которую как текущую должна предварительно 
получить субъект сессия. В противном случае субъект-сессия не сможет получить роль или 
административную роль как текущую. Также отметим, что в условии описан конкретный 
способ задания запрещающей роли для индивидуальной административной роли или 
индивидуальной роли некоторой учётной записи пользователя, делающий такую за¬ 
прещающую роль текущей для всех субъект-сессий функционирующих от имени этой учётной 
записи пользователя. Возможны другие более «гибкие» способы применения запрещающих 
ролей. Например, в некоторых случаях в ОССН требуется ограничить права доступа субъект- 
сессии (процесса), активизированного из конкретной сущности (исполняемого файла). Тогда 
роли, которая обладает правом доступа на выполнение ехесиіег к исполняемому файлу, 
можно с помощью функции сопзігаіпімя назначить соответствующую запрещающую роль. 
После чего родительский процесс должен сначала получить как текущую эту роль вместе с 
запрещающей ролью, активизировать из исполняемого файла новый процесс, который 
“наследует” от родительского и запрещающую роль. 

Таким образом, включение в МРОСЛ ДП-модель ролевого управления доступом с 
запрещающими ролями в перспективе реализации его в ОССН обеспечит гибкость такого 
управления доступом, которая, как правило, достигается только при использовании 
атрибутивного управления доступом (АКгіЬиІе ВазесІ Ассезз СопігоІ- АВАС) {117}. При этом в 
отличии от АВАС в рамках МРОСЛ ДП-модели осуществляется строгое теоретическое 



доказательство условий безопасности моделируемого механизма управления доступом 
ОССН. 


Де-юре правила преобразования состояний 


на уровне ролевого управления 


Таблица 2 Л 


Исходное состояние С 


доступом иерархического представления МРОСЛ ДП-модели 


Результирующее состояние С 


х Е 8, и $ і/, (х, изегз.аЛтхп.тоІе, геаДи), 

(х, педаІіѵе„гоІез_а<ітгп-гоІе, геа Д,,), ( х, гоІез.аеітіп_гоІе , 
а а ), (х, асітіп.гоІез.а(ітгп.гоІе, а а ) € А А, где 
«а € { гсай а , іитпіе,,} 


х Е 5, и Е V, изег~ г (и) = 0, (х, изегз_а<ітгп_гоІе , геаД,,), 
(х, педаігѵе-гоІез.а(ітчг_гоІе, геаДа), (х, асіттггп^гоіез. 
асітіп_гоІе, гешіо), (х, гоІез.аЛтгп.гоІе , геаДц) € А А 


сгеа4е_ивег(ж, и) " 

V *= ^ и {**}. >4 Я' = ЛЯ Ы {и.аДттп}, РА'(и_аДтт) = 0, 

(іігес? (іискітіп) = зкагесі-сопіахпег' (и_аДтт) = Ігие, 
гоІе.пате'(и_а<ітп%п) = ѴвЛлт", Я^(щаДтт) = 0; Я' = Я ІД 
и{и_с}, РЛ'(и_с) = 0 , гіггесе'(щс) = зЛагеД_сопіаіпег'(и_с) = ігие, 
гоіе.пате' (и.с) = "и_с", Я^(и_с) = 0, АРА'{а<Іттп-гоІе5_а<іт\п_тх>Іе) = 
= АРА(айтпхп.го1ез-а<1тхп-го1е) и{(и.аДтіп, ошгѵ)}, 
АРА'(по/е5_аДттп_гс>/е) = АРА(го/ез_аДтіщгт>/е) и{(и_с, ои/тѵ)}, для 
аг е ЛЯ выполняется АРА'(аг) = АРА(аг) и{(и_а(ітт, ехеси1е г )} Ы 
и{(щс, ехеси1е г )}, ЛРЛ'(щайтгп) = {(и^айтгп, а г ): а г € {яеаДг, 
іѵг*1е г , ехесиіе,}} Ы {(и_с, а г ), (соттоп_го*е, а г ): а г € {геакг, и/піе г , 
ехесиіе г }} и {(г, ехесиіе г ); г € Я' и ЯЯ и ЛЯ'} Ы {(пг, геаі-): 
пг € согізігаіпіхп(соттоп_гоІе)} 
с*е/еіе_гівег(ж,-и) 


х 6 5, и € I/, : 6 О, (х, г, итІе а ) Е Л 


У' = и\{и}, АН’ — АН \{и_аДт*п}, IV — Я\{и_с} для аг € ЛЯ' 
выполняется ЛРЛ'(аг) = АРА(аг) \({(и_аДтт, а г ): а г 6 Н г } и 
и{(и_с,а г ): а г € Яг}) 
деі^-ивег _аііг{х^ -и, х) 

Ѵ'(г) = ((если и$ег(х) = и или (х, изегз.а(ітпгп.гоІе, гешіа) Е Л Л, то 
{(г # ,а г ): (г',а г ) € ЛР/1(и.агітіп)}, иначе "0"), (если изег(х) = ?і или 
(х, изегз.аЛгпгп.гоІе, геаііа) Е Л Л, то (в 6 5: изег(з) = и}, иначе "0")) 
ассееа_и>ггіе(ж, у) 


х Е .9, у Е ЯЫЯиЯЯи ЛЯ, существует г € ЯЫ ЛЯ: (х, г, 
геа<іа) Е ЛЛ, (если у € Е, то (у, и/гііе г ) 6 РЛ(г), сущест¬ 
вует контейнер с € С такой, что ехесиіе_сопіатег(х, с, 
у) = Ігие, и не существует запрещающей роли пг € ЯЯ 


если у Е Е, то А' = А и {(х, у, и/ліе«)}, если у Е Ни ИНи АН, то 
ЛЛ' = ЛЛ 1-){(х, у, шпіе а )} 


Продолжение табл. 2.1 

Насадное состояние <7 

Результирующее состояние Д' 

/ такой, что (ж, пг, ппа<4,) € ЛЛ ж (у, и/п<е г ) С РЛ(пг)), (если 

1 у Е В и ЯЯ Ы ЛЯ, то (у, иггчіе, ) С АРА(г)] 



ассев«.геа(і(х, у) 


I х € 8, I/ € Е и В и ЯЯ 1_» ЛЯ. существует г € В и АН; (х, г, ггаД и) Е 
I € ЛЛ, [если у € то (у, тааД, ) е РЛ(г) и существует контейнер 
е С тако*, что ехесхііе.соп(ахпгг(х, с, у) = ігие, и не существует 
I запрещающей роли пг е ЯЯ такой, что (ж, пг, гелД„) Е Л Л и (у, 

Г л-оД.) е РА(пг)], /если у € Я О ЯЯ Ы ЛЯ, то (у, геа^) е ЛРЛ(г)}, 

/ [если у Е Я1 г ЛЯ, то для всех пг е сопз1тхх*п1,ук(у) верно (х, пг, 

[ геаО„) е ЛЛ[ 

гіе1еІе-ассеяв(т, у, а а ) 

I т Е 8, у€ ^СіЯС* ЯЯ Сі ЛЯ, (х, у, о в ) (6 Л и ЛЛ, [если у Е ЯЯ и г> а = 

I = геас/о, то не существует г € ЯіД А В такой, что (х, г, гешЪ) Е АА 
| к у Е сопзітаіпіх я (г)} 

« 7 гяг» 1 _>-іуЫя(х, г, {(у, о^): 1 ^ А:}) 


если у Е Е, то А' = Ли Цх. у, ге«<*о)}. если у Е Ни ЯЯ О ' 
и ЛЯ, то АА* = ЛА и {(х. у. геаД,)} 


если у Е Е, то А' = А\{(х, у, о а )}, если у е йі) ЫНи АН, | 
то АА‘ — АА \{(х, у, « а )} 


х € 5, г е Ии ЯЯ Ы ЛЯ, [у € Е, о^ ^ ^ Е {ѵтіе-ггеасіг , ехесиівт-}, 

Лгесі(у) = Ігие, (х, г, хѵгхіе ,,) & ЛЛ|, (существует г' 6 ЯЮ ЛЯ: (х, г', 
геа4п) € А А, (у, оит,) е РЛ(г’)], (существует контейнер с. Е О такой, 
что езхсиІе~сопІалпет(т . с, у) = Іт~ие|, (не существует запрещающей 
роли пг Е ЯЯ такой, что (х, пг, геасі,) € Л Л и (у, оѵлгг) Е РА(пг)], 
где 1 ^ < к 

гѵпгоѵе-гід/іІа(х, т*, {(у, а г ^): 1 ^ у 


РЛ'(г) = РЛ(г) и {(у, а гі ): 1 ^ 3 ^ А:}, если Яе(у) = 

= {у' € А/к(у): ЛгесІ(у') =/аІ*е}, то для всех у' < у верно 
РА'(г) = Р Л(г) У {(у% агі): 1 < і ^ А:} 


х С Я, г € К Ы ЯЯ ід ЛЯ, (у е Е, €Жту Е {ѵѵгіІе г геаЛг , стссѵАе г ), 
ІЦѴі^гэѴ- 1 ^ ] ** ^} С РЛ(г), Д»гесі(у) = ігие, (х, г, шгтіе а ) € АА|, 
^существует Р е Ки АН: (ж, г', геас^) ^ Л Л, (у, оит,) ^ РЛ(г / )|, 

, Ѵ с утесті»>у<т коитсЬвер с С С такой, что ехссиіе-сопіаіпег^х, с, у) — 
\ * іт-ие\, \и« существует ѵтревдющвй роли тгг 6 ЯЯ такой, что 
V ^ . пт . т ^.) ѵ - АА м (у. о^пту-) ^ РА(пг)\, где X. ^ ^ ^ Іс 


к}) 

РЛ'(г) = РЛ(;)\{(у, ): 1 ^ у ^ к}, если //д*(у) = 

- {у' Е ІІЕ^и): іі»песі(у') = /аізе], то для всех у' < у 

верно РА’(г) = РЛ(г)\{(і/,агг>^: 1 < > ^ Аг> 





























Продолжеим 


Исхсуѵнос состояние С? 


Результирующм состояние Сі' 


яе<_еп6*іулп«пег(*, г, г’, |/) 


х € 5, г, г' € Ли АЛ, у € Ь’, {(ж. г', шпІе 0 ), (л, епіхіхез-асітхги-тоіе , 

»та^)} С АА. 1({(-Г. г. теа<іп ). (х, г. и/пйе,»)} С АА, (у, оит,) € 
е ЛА(г)) или (для всех г" € Ли 4Л выполняется (у, оит, ) ^ 

Яі4(г"))), (блеску) = Ітхіе, (существует контейнер с € б” такой, что 
ехес«*е_с4т*<млег(.г, с, у) = Іт~ие] , (не существует запрещающей роли 
пг € ЛЛ такой, что (г, пг, геа<і„) € И/ и (у, оит, ) <Е ЛА(пг)( 

веі.виЬ^'есі_ои;пег(ж, г, 


РА'(г) = ЯА(г)\{(і/, оит,)}. РА'(г') = РА(г') и {(.V. 
ошпг)), если НгЛѵ) = {у' € Н Е (ѵ) <іггес*(у') =/аізе), 
то для всех і/ < у верно РА'(г-) = РА(г)\{(у / , оит,)), 
РА'(г') = РА(г') и {(у', оит,)) 


У) 


х, у 6 5, г, г' € Ли АЛ, {(х, г', шгг(е а ), (х, зиЬ]есіз.а<ітхгх^гоІе, 
геа«іо)} С АА, (({(х, г, яса^), (х, г, и/гг^е,,)} С АА, (у, оит, ) е 
€ РА(г)) или (для всех г" е Л Щ АН выполняется (у, оит, ) ^ 

^ РА(г"))], (не существует запрещающей роли пг е ЫН такой, что 
(х, пг, гесиіа) е А А и (у, оит,) € РА(пг)] 

аА/.педа<*ѵе.ошпег(х, пг, у) 


РА'(г) = РА(г)\{(у, оит,)}, РА'(г') = РА(г')и {(у, оит,)} 


х € Л, у € Л и Л, пг € ЛЛ, (х, пг, хиггі.е а ) € АА, (существует г' е 
Ли АН: (х, г', теаАа) € АА, (у, оит,) € РА(г')], (если у € Л, то 
<іггссі{у) = *т-ие, существует контейнер с е С’ такой, что 
ехесиІе_сопІагтіет(х, с, у) = Іт~ие], (не существует запрещающей роли 
пг' е ЛЛ такой, что (х, пг', леааЕ,,) е АА и (у, оит,) € РА(пг')) | 

гетоѵе.педпі*ѵе.ои;пег(х, пг, у) 


РА'(пг) = РА(пг) и{(у, оит,)}, 

— {У' € Н Е (у): 4ггесі(у‘) = /аізе ) . то для 
верно РА'(г) = РА(г) и {(у', оит,)} 


В и //*: (у) = 
V* <■ V 


х € Л, у е В и Л, пг е //Л, (х, пг, хм~хІе а ) € А А, (у, оит,-) е РА(пг) 
(существует г' е Ли АЛ: (х, г*, геаа^) е А А, (у, оит,) € РА(г')), 

(если у ^ Е, то (іхгссі^у) = $гие, существует контейнер с е Г/ такой, 
что схесиіс_сопгаіпег(х, с, у) = <гие], (не существует запрещающей 
роли пг' е ЛЛ такой, что (х, пг', геос^,) е А А и (у, оит,) € РА(пг / )] | 

дгапІ^асІтіті—ЫдМа (х, пг, {(г, и^) 
I - г С .V, аг 6 АЛ, г € Ли ЛЛ и АЛ, сж Г у € {шпіе г , геасі, }, (х, ог, 

| гип<е.,) € А А, (если г€ Л, то (х, го1ез.а<1тхп_го1е, геа<^,) € А А), (если 


РА'(пг) 

= {у' <Е Не(ѵ) ЛгесЦу') 
верно РА’(г) = РА(г)\{(у' 


РА(пг) \{(у, оит,)}, если у € Р и Н&(у) = 

= /оІ5е} , то для всех у' < у 
оит,)} 



2.2.3. Де-юре правила преобразования состояний 

В рамках МРОСА ДП-модели используются правила преобразования состояний из 
множества ОР, которые по аналогии с моделью Таке-Огапі классифицированы на де-юре 
правила — правила, которые требуют реализации в ОССН, т. е. приводящие к «реальным» 
изменениям её параметров: изменению множеств прав до- Р ступа ролей, получению 
доступов субъект-сессий к сущностям ила ролям и т.д.; и де-факто правила — правила, 
которые не требуют реализации в ОССН, так как используются в модели для отражения 
факта получения субъект-сессией де-факто владения субъект- сессиями или факта 
реализации информационного потока по памяти или по времени. В связи с этим на уровне 
ролевого управления доступом иерархического представления МРОСА ДП-модели задаются 
только де-юре правила преобразования состояний. При этом в результатах их применения 
не указываются неизменяющиеся элементы состояний системы. 

В рамках уровня ролевого управления доступом МРОСА ДП- модели заданы 35 де- 
юре правил преобразования состояний, условия и результаты применения которых 
соответствуют предположениям модели. Эти правила предназначены для формального 
описания (спецификации) следующих основных функций механизма управления доступом 
ОССН: 

• создание, удаление, переименование, получение или изменение параметров учётных 
записей пользователей, ролей, запрещающих ролей, административных ролей, сущностей 
или “жестких” ссылок на них, субъект-сессий; 

• получение доступов субъект-сессий к сущностям, ролям, запрещающим ролям или 
административным ролям; 

• изменение прав доступа ролей, запрещающих ролей или административных ролей к 
сущностям, субъект-сессиям, ролям, запрещающим ролям или административным ролям; 
















изменение иерархии сущностей, ролей, запрещающих ролей или административных 


ролей; 



Исходное состояние С! 


Результирующее состояние СУ 


сгсаІс.аопіо.іпе.і-(а : 1 

• € 5 у € Е, пате € ХАМЕ \({""} и {епШу_паше(г, у'): у' 6 
€ Н&{*)})• (*> -• «"'»*««) ^ А, если г € С, то [существует г 6 Пи 
иАЯ такал, что (х, г, геа<і«) € АЛ и (х ехесиіе») Е РА(г)|, Не(%/ 

= ( у' е //;:(;) Лтесі(у') = угі}, [если уі = й-ие, то <іігес((с) = 
Ігие], [ве существует запрещающей роли пг в МН такой, что (яг, 
пг. тсаЪ) е АА н (г, ехеспіе г ) 6 ЯЛ(яг)] 


г ё В, у € Я Е {-). Н Е (ѵ) = 0. (*. г - “'’•>*=«) е А, если у € Е, 
х € Е?, то [не существует г' Е С такой, что г' ^ г и і/ € )• 

и |епіі^пат«С-, у)І - 1). (существует г Е Ли ЛЯ такая, что (х, г, 
геосіа) Е А А И (г ехесиіе г ) Е РА(г)], [если 5 Лагей_соп«атег( 2 ) = ігие, 
то существует г 6 Яеі АЯ такая, что (х, г, геаі,) Е -4-Л и (у, аиш , ) Е 
€ РА(г), и не существует запрещающей роли пг € ЛГЯ такой, что (х, 
пг, лешій) € Л А и (у. оинѵ) € РА(пг)|, [не существует запрещаю¬ 
щей роли пг е /«Я такой, что (х, пг, геа^і) € А А и (г, ехесиіег) € 

Е РА(пг)] 

сгеаІе-ІшгсІ-Ііпк(х , і/, пате, х) 


г' Е Я и ХПи А Я выполняется РА'(Р) — РА(г') и Цу. <*гУ 
(с,а г ) € РА(г '))1 
угі, пате, к) 

епі*іу_лате'( 2 , у) = {пате}, Н’ Е {г) == //е(з) и {у), 
я' (у) _ 0 , если г е С, то Е' = Б У {у}, С = С и {у}, 
зиагееі-сепіаіпет' (у) - /аіее, гі’.тесС (у) = усі, V (у) — 0, 
[если у<і = ігие, то РА'(изет(,х)-с) = РЛ(юег(і) с) и«у, 
ошп,)}]. [если у а= /аізе ІСЕ С такая, что Лгесі(с) = 

= ігие, //,,(<■) = {у' е Н Е (с): сііге сі(у') = /аІ 5 е> и 
у < с, ТО АЛЯ всех г' € й и ЛГЙ и ЛЯ выполняется 

РЛ'(г') = РА(г') и {(у, огг)- (с, о,) 6 йА(г')» 
с1Ые1е-.еп1Ну(х, у, т) 

если у е Е, г е С, то Е' = Е\{у}, Н' Е (,з) — Яг;(с)\{у}, 
[для г е пи МН и АН выполняются равенства РА’(г) = 
= ,РЛ(г)\{(у, Ог): ог г € й,}. А' = Д\{(*.у,с»о): а е 3, 
°о Ё На } ] 


х ё Я, у € О, г € С, [существует о 6 С: ехесиіе-сопйкпет^х, с, 
у) = ігие], [(х, с, и/г»(е а ) е А, существует г 6 Я Щ АН такая, что 
(т, г, гссиЬ) 6 А А и (а е*еси!е г ) е А4(г)|, пате 6 ИАМЕ Ѵ({""} и 
и(епй(у.пате(с, у'): у' € %(*)}), Й ь (г) = {у‘ 6 Нв(г): сіітесі(у') = 
— Щпесі(у)}, [если <йгесі(у) = ігие, то гіігесі(л) — (т*ие[, [если 
Іітг-с((у) — ]аІзе, то существует г' 6 С такая, что іігесі(г) = ігие, 

У -с ~~’ лля всех і/ < г' рсрпо ,•/) = /візе], [не сущест- 


стііі(у_пате г {а, у) — епіхіу_пате(с, у) 11 {пате [, іі ' 1 .- (с} ‘ 
= Н Е (г) и {у} 










































Исходно* состояние Г/ 


Продолжение табл. 2.1 


Результирующее состояние О* 


і вует запрещающей роли пг с ЫН такой, иго (х, пг, геаД,) € АЛ и 

I (г, ехесиіе, ) е РА(пг)] 


<іс/сіе^аг^іпА;(г, у, патл, х) 


х Е Я. у Е О. г Е С. у Е Не(х). пате Е епіі/у_пате(г, у), [сущест- 
I вует <Е С такой, что а' ^ * и V € // К (г')|. [(ж, г. шпіг.. ) 6 Л. 

/ существует г е «и .4/? такая, что (х, г, п-о*. ) е ЛЛ и (г. ехесЩе. ) е 
I ^ РА(г)], /если зАопаі.сопіо»пег(г) = ігие, то существует г Е Яіі^й 
| такая, что (х, г, твш^) € АЛ т (у, оит.) е Л4(г), к не существу¬ 
ет запрещающей роля пг € ЫН такой, что (х, пг, геагі,,) 6 ЛЛ и (у, 

I щеп.) е ЯЛ (пг)), (не существует запрещающей роли пг е ЛЛК такой 
I что (х, пг, г еші.) е ЛЛ я (с, ехеспСе, ) е ЯЛ(пг)І 

сте<д/е_г«?/е(;*: э 

і т € Я, (х, та, іт <*„) €ЛЛ, г^ЯиЛГЯи ЛЯ. если гге (Ни 

I илгл и ал) \ (ѵ.ломіы іо і/.ноьвз и соммоы.ноьез и зал), 

I то [(если гг е К, то (х, гѵіез.шітпітигоіе, «<,) с ЛЛ|, [если гг 6 ЛГЯ, 
то (х, пеуагіее-пэ/е5_шігат. по/е, о,) с ЛЛ], (если гг 6 ЛЯ, то (х, 
аЛтп-поіез.щйпіп-гЫе. о„) е ЛЛ), где л„ е (гм*,, чгііе,,}, [поте 6 
I € ЫАМЕ \({”"} и {пеіе.поте(г',г"): г', г" е Ли ЛЯ Ы ЛЯ}))] 


епМу.пате' (х, у) = елі**у_гіот«(;:, у)\{ пате}, 
епШупате'(;. у) - 0, то Я' к (г) = //к(*)\{у) 


пате, г*) 

»п( г -0 = Лй(гг) и(г), //'„(г) - 0, го1сгите , (гі, г) - 
— патл, (іхгесі' (г) = іг-ие, з/іагесі.сстіатег^г) = Сгис, 
Р>*'(г) = 0, если гг € Я. то Я* = Я и {г}. АРА' (тоіез _ 
аеітгтг_гоІе ) — АРА(гоІез.аДтпгп^гоІе) и{(г, ощтѵ), (г, 
ехесвіе,)} и {( г , геасі,): (гг, геасі, ) е АРА(гоІез.аДтхп. 
гоіе)}, если гг Е П и ЛЯ, то сопзЬгагп^ „(г) = 0, если 
и* € то ~ МЯ и{г}, АРА' (псдаііѵе-тоіез-сиітггѵ. 
тѵіе) = АРА(педаілѵе-гоІсз _ аДтіп.тх?Іе) и{(г, оиліг), (г, 
ехесміе Г )} и {(г, геаД.): (гг, геаД ) Е ЛРЛ(пеуаі»ве_г©іе,*_ 
асіт\гх.тх)1е) }, если гг е ЛЯ, то ЛЯ 7 = ЛЯ и{г>, 

АРА (а<Ітіп.тъІез.аДтіп-тоІе) = Л РА ( аДтіп. гоіез. асітпіті. 
і'оіе) и{(г, охцпг), (г, ехесиІе г )} и ((г, гг. а Л, ) : (гг, геаД) Е 
е АРА{а<Ітіп.гоІез.аДтіп.гоІе)}, АРА' (г) = ((г', 
ехесиІе г ) г’ Е Пи ЫН и АН'}, для аг € ЛЯ \{’аДтт. 
гоІез.аДтіп-тоІе гоіез.аДтіп^поІе, педаІхѵе.тоІез.аДтіп-гоІе) 
выполняется ЛРЛ'(аг) «= ЛР>І(аг-) и {(г, ехееоіе,)) и {(, 
то<іг): (тл пга4 ) Л Я^(аг)} _ 


Е 


Искал <-«->« 1,1 1 


Прилолжниио тпбл. 2Л 


<ІеІеео-гоіс(х, г, гг) 


Результирующее состояние С»” 


х С .9, г* б ///)(п), (х, гг, іѵп^е,,) € Л Л, если г О. ( Я • 1 Л'/Ѵ і і ЛЯ)\ 

\ (І/.АОМІЫ ' > Ѵ.НОЬВЗ и СОММОЫ.НОЬЕЗ и 5ЛЛ), то /Гц (г) — 
= 0, /если г € Я, то (х, гоІез.аДтш.г'оІс, <* а ) С Л Л), (если г-.: Л г /?, 

•го (х, псдсхЫѵе _гоісз. скітътг-.т'оіе, а а )/, [если г е ЛЯ, то (х, асітіп 
гоіез.асітгп-гоіе, а„) <Е А А], г де сг в е (геогі,,, ит(.е„ }. [не существует 
гг* е Ли //Я и ЛЯ такой, что гг' ^ гг и г € //^(гг 7 )) 


стеа4е_/іаг«ПіпЛ.гЫе(*, г, г*) 


//'^(гг) — //«(гг) \{г^, для агс ЛЯ* выполняются ра¬ 
венства ЛРА'(аг) = АРА(аг) \{(г, а г ): а Р € Я г ), Л Л' = 
= А А \{(в, г, а в ): в € Я, и а € Яв), если г € Я' и 
ияя' и ЛЛ', то Л' - Л\(г}, ЛЯ* = ЛЯ \{г>, ЯЛ' = ЫН \ 
\{г}, для всех г' € Я' и ЛЯ' верно сопзітхпі^ я (г') — 

= сопз*гот<' ѵп ( г ')\(т> 


€ .9, не выполняется условие г* < г, (х, гг, хиггіе ,, ) € ЛЛ 
^ (ЯЫ ЯЯ и ЛЯ) \ (<7 АОМІЫ и 1/_ЯОб/5.9и СОММПЫ ПОГРЯ). 
г $ ЗА Я. то [если гг Е Я, то (х, го1ез.аЫтггг.гг>1е, л„ ) *^ Л Л), [если 
гг е А/Я, то (х, педаіхѵс-гоісз-асітгті^гоіе, а п ) <Е Л Л], [если гг е ЛЯ, 
то (г, асітпхтг ггзіев сыітхп гоіе, с *„) € Л Л), где а а Е {пеаЛ,, шп<е„ } 

<ісІсіс-/іаг(і-Іігік^гЫе(х, г. гг) 

Е і>’, г € і/«(гг), (х, гг, ыпіе„) е Л Л. если г- € (Я О ЯЛ и //^(гг) = //«(гг) \{г} 

ЛЛ)\ ( и^ЛПМІЫ і_) и^НОЬЕБ и СОММОЫ.ПОЬЕЗ и ЗЛН), то [ес¬ 
ли г € Я, то (х, гѵ7Іез_асІтпіп_гоІе, ог«,) € Л Л], (если гг е ЯЛ, то (г, 
пеуа/*і>е_го/ел_а«/ттн_го/е, о а ) Е Л Л], [если г Е Л Л, то (х, лгігліп. 
тоІез-а<ітгп.гоІе , с»,,) Е ЛЛ[, где « в Е { юса с*,,, г^г» С е, ж }, [существует 
гг' Е Яи ЯЛ и ЛЯ такая, что гг' / гг и г € //«(гг 7 )] 

гспат(і-еті(і(і/(х, у , Ыіі^ппте, ттте, г) 


Н' п (гг ) = Нп (гг) и{г}, если г, гг Е Яи ЯЯ и ЛЯ, то 
го/е пат«^(гг, г) = гоіе.патпе^г^ , г) и г Е //«(гг'), для 
аг Е ЛЯ таких, что (гг, геас/,-) Е ЛРЛ(аг), выполняется 
АРА'(аг) = АРА(аг) и{(г', г еасіг): г' < г) 


Е Я, у Е //б(-0. оІ<і—т\атс <= епігіу-патпе^х, у), пате С ЫАМЕ 
\({ ии } и {«гт*еиу_ пате(г, у'): у' Е Яб(*)}). (^. Ѵ/гі/е в ) € Л, ес¬ 
ли у Е Е, г Е С*, то [существует г Е Я и ЛЯ такая, что (х, г. геасі ,, ) Е 
Е Л Л и (г, ехесулІе г ) Е ЯЛ (г)], [если д/іаге<і_сол/а*»г«г(г) = Ігие, то 
существует г Е Яи ЛЯ такая, что (х, г, гсагі,, ) Е Л Л и (у, ашПг) Е 
Е РЛ(г), и не существует запрещающей роли пг Е ЯЯ такой, что (х, 
пг, гса«іу,) € Л Л и (у, оплѵ) Е РЛ(пг)], [ие существует запрещаю¬ 
щей роли пг Е ЯЯ такой, что (х, пг, гса^,) С Л Л и (г, ехесхііе, ) Е 
Е РА(пг)1 


епШу_пате(г, у) = (епе«/у..пате(г, у) и 
У{пате } )\{ оШ.пате } 


Продолжение табл. 2.1 


Исходное состояние <і 


Результирующее состояние Сі' 


геииг«с-гЫк(х, гу, пате) 


х Е 3, если губ (Я и ЯЯ и ЛЯ)\ ( Ѵ-АОМІЫ и Ц.НОЬЕЗ и СОМ- 
МОЫ.НОЬЕЗ и ЗАН), то пате Е ЫАМЕ \({- м ) и (гоіе. пате (г', г") 
г • г Е ЯЫ ЯЯ и ЛЯ>), [если гу Е Я, то (х, г оІез.а<ітіп.гоІе, теаД,,) е 
« г АЛ), [если гу Е ЯЯ, то (х, педаііѵе-тоіез _ а<ітіп.гоІе, геаД^) Е Л Л), 

/если гу Е ЛЯ, то (х, асітіп. гоІсз.асІтпіті_гоІе, гсаД,) е Л Л], [для гг Е 
Е ЯЫ ЯЯ и ЛЯ: гу е //«(гг), выполняется (х, гг, іипіе^) Е ЛЛ/ 

геа<і_сопІ/ііпсг(г, у, г) 

х Е Я. г Е О, (х, г, итг»*е а ) е Л, если у € С’иЯиЯЯиЛЯ. то существу¬ 
ет г е Я Ы ЛЯ: (х, г, геа«4.) € Л Л, [если у Е С, то [(у, геаД.) € ЯЛ(г), 
существует г' Е //и ЛЯ: (х, г', гсасі, ) € ЛЛ. (у. ехесаіе, ) е ЯЛ(г'), и 
существует контейнер с Е С: ехесиСе.сопіатег(х , с, у) = (г-ие\, и (но 
существует запрещающей роли пг Е ЯЯ такой, что (х, пг, геаД,) Е 
€ АА и либо (у, геасі,) Е РЛ(пг), либо (у, ехесиІе г ) Е РЛ(пг)/), (если 
V € Яи ЯЯ и ЛЯ, то (у, гкасі,- ) Е ЛЯЛ(г)] 

дѵі -г.піііу сі//г(х, у, х) 

х Е Я, у Е ЯГ, г Е О, (существует контейнер с Е С* такой 
схесісіе_соп/агпсг(х, с. у) = /гие|, (х. г, ш<в„) € Л 


для гг Е ЯыЯЯыЛЯ таких, что гу Е //«(гг), выполняется 
гоіе-пате' (гг, гу) — пате 


если у Е С*, то Ѵ'(г) = { епШу..патс(у, е): с € Н ь (у», 
если у Е Я и ЯЯ и ЛЯ, то Ѵ # (г) = {л>Іе.патв(у, г): 

Г € Яц(у)} 


С Я, у е 5, г € О, (х, г, и/гхіе,,) е Л 


г (■=) — (с/* Т1 гсг(у), (если у Е то 5/іаге<і_сс>піатег(у), 
иначе 4 /аізе ” ), (если у Е О. го |{е € С*: у Е // Е (*)Ц. иначе 
•і"). (если [существует г е Ни ЛЯ: (х, г, геасі,,) е Л Л, (у, 
отып, ) е РЛ(г), и не существует запрещающей роли пг Е 
• ЫН такой, что (х, пг, геасі,,) Е ЛЛ и (у, ошп г ) € РА(пг)\ 
или [(х, епііі«ез_асіт*п^гоіе, геаД ,) е ЛЛ], то {(г',а г ): 
г' Е Ни ЯЯ и ЛЯ, (у, а г ) € РА(г')}, иначе ’*0 И )) 

с/с-< _я«Ь)кгі у, г) 

Ѵ"(г) — (изег(*), (если [существует г Е //и ЛЯ: (х, г, 
геаД л ) Е ЛЛ. (у, опт,-) Е РЛ(г), и но существует запреща¬ 
ющей роли пг Е ЯЯ такой, что (х, пг, гггаД ,) Л Л и (у, I 

опт,) Е РА(пг)) или |(г. лілЬуегІз.аіІгпіп тіг, геаД, ) , Л Л/. / 
т° {(г*, ои^у): г' е- /Л< ЯЯ О ЛЯ. (у. оі/ті. ) , *'Л(г ')). ] 




















































• управление множествами запрещающих ролей для ролей и административных ролей. 

Приведённые правила в основном соответствуют применяемым ОС семейства Ипих 
подходам к реализации механизма дискреционного управления доступом, некоторые 
параметры которого выражены с помощью ролей. Рассмотрим подробнее условия и 
результаты применения де-юре правил преобразования состояний. 

Де-юре правила вида сгеаІе_изег(х, и), с!еІеіе_изег(х, и) и де!_изег_а11г(х, и, г) 
позволяют субъект-сессии х создать, удалить или получить параметры учётной записи 
пользователя и. Во всех случаях, кроме получения параметров, требуется наличие у субъект- 
сессии х доступов на чтение к специальным административным ролям изегз_асІтіп_гоІе и 
педаііѵе_гоІез_асІтіп_гоІе. При этом в последующем состоянии иерархия ролей 
модифицируется (создаются или удаляются индивидуальная роль и индивидуальная 
административная роль, назначаются или удаляются административные права доступа к 
ним) в соответствии с условиями предположения 2.2. Для создания или удаления требуется 
наличие у субъект-сессии х доступов на чтение, а в случае создания и на запись, к 


























специальным административным ролям гоІез_адтіп_гоІе и адтіп_гоІез_адтіп_ гоіе, так как 
именно эти роли получают права доступа владения к создаваемым в соответствии с 
предположением 2.2 при применении правил индивидуальным административным ролям и 
индивидуальным ролям учётной записи пользователя и. Также при создании индивидуальной 
административной роли новой учётной записи пользователя даются административные 
права доступа на чтение ко всем запрещающим ролям, заданным для общей роли. В случае 
удаления учётной записи пользователя требуется, чтобы в этот момент времени от её имени 
в системе не функционировала ни одна субъект-сессия. При получении параметров при 
условии, что х Функционирует от имени и или обладает текущим административным доступом 
на чтение к роли изегз_адті_.гоІе, в сущность г (к которой субъект-сессия х должна иметь 
доступ на запись) записываются данные о ролях и правах доступа к ним, которыми обладает 
индивидуальная административная роль и, и записываются данные о субъект-сессиях (в 
ОССН идентификаторы субъект-сессий), функционирующих от имени и (в этом случае 
полные данные об учётной записи пользователя предоставляются либо субъект-сессии, 
функционирующей от её имени, либо субъект-сессии, которая может администрировать эту 
учётную запись). 

Де-юре правила вида ассезз_геасІ(х, у) и ассезз_ѵѵгііе(х, у) позволяют субъект-сессии 
х получить к сущности, роли, запрещающей роли или административной роли у 
соответствующий доступ или административный доступ. Для этого при получении 
административного доступа требуется наличие у х текущей административной роли г, 
содержащей соответствующее административное право доступа к у, а при получении доступа 
наличие текущей роли или административной роли г, содержащей соответствующее 
административное право доступа к у, а при получении доступа наличие текущей роли или 
административной роли г, содержащей соответствующее право доступа к сущности у, и 
отсутствие у х текущей запрещающей роли обладающей этим правом доступа к у. При этом 
требуется, чтобы доступ к у был предоставлен с учетом прав доступа текущих ролей, 
запрещающих ролей или административных ролей субъект-сессии х к сущности-контейнерам 
или ролям-контейнерам, содержащим у. Кроме того, если используется де-юре правило вида 
ассезз_геад(х . у) для получения субъект-сессией х административного доступа на чтение к 
роли или административной роли у, то требуется наличие у субъект-сессии текущих доступов 
на чтение ко всем запрещающим ролям, заданным функцией сопзігаіпізын для у. Де-юре 
правило де!е1е_ассезз{х, у, а а ) позволяет субъект-сессии х, обладающей доступом а а к 
сущности или административным доступом к роли, запрещающей роли или 
административной роли у, удалить этот доступ, при этом не допускается удаление у х 
административного доступа на чтение к запрещающей роли у, когда эта субъект-сессия 



имеет текущую роль или административную роль, для которой запрещающей является роль 
У- 

Де-юре правила вида дгапІ_гідЫз(х, г, {(у, а г і)-. 1 < у < к}) и гегпоиех_гідЫз(х, г, {(у, ар): 
1 <у < к}) позволяют субъект-сессии хдобавить или удалить, соответственно, права доступа 
к сущности у из множества прав доступа (за исключением права доступа владения) роли или 
административной роли г. Возможность с использованием правил одновременного 
изменения нескольких прав доступа к сущностям с косвенной меткой осуществляется 
одновременно с изменением прав доступа к единственной существующей по условию 8 
предположения 2.2 соответствующей сущности-контейнеру. Для применения правил 
необходимо наличие у субъекта-сессии х доступа на запись к роли г и наличие текущей роли, 
обладающей правом доступа владения к сущности у, а также отсутствие у х текущей 
запрещающей роли, обладающей правом доступа владения к у. При этом требуется, чтобы х 
могла получить доступ к сущности у с учетом прав доступа к сущностям-контейнерам, 
содержащим у. 

Де-юре правила вида зеІ_епМу_оѵѵпег(х,г,г’,у) и зеІ_зиЬіесІ_оѵѵпег(х,г,г’,у) позволяют 
субъект-сессии х либо изменить, либо задать единственную роль-“владелец” (имеющую 
право доступа владения) к сущности или субъект-сессии у соответственно, с роли или 
административной роли г на роль или административную роль г’. Для этого субъект-сессии х 
необходимо иметь административные доступы на чтение и запись к г и на запись к г'(чтобы 
иметь возможность менять права доступа данных ролей), а также иметь административный 
доступ на чтение соответственно, либо к административной роли епШіез_асІтіп_гоІе, либо к 
зиЬ]есІз_адтіп_гоІе. При этом у субъект-сессии х должна отсутствовать текущая 
запрещающая роль, обладающая правом доступа владения к у. Непосредственно изменять 
роль-«владелыда» разрешено только к сущностям с прямой меткой. Изменение роли- 
«владелыда» к сущности косвенной меткой осуществляется одновременно с изменением 
роли-«владельца» к единственной существующей по условию 8 предположения 2.2 
соответствующей сущности-контейнеру. Когда изменяется роль-«владелец» сущности у 
требуется, чтобы х могла получить доступ к сущности у с учётом прав доступа к сущностям- 
контейнерам, содержащим у. 

Де-юре правила вида абсІ_педайііе_оѵѵпег(х, пг,у), гетоѵе_педаІіѵе_оѵѵпег(х, пг, у) 
являются аналогичными правилам вида дгапі_тідМІз(х, г, {(у, ар)' 1 < \ < к}), гетоііе_підНІз(х, г, 
{(у, ар): 1 й\< к}), зеІ_епМу_оѵѵпег(х, г, г', у) и зеІ_зиЬіесІ_оѵѵпег(х, г, г у). Они позволяют 
субъект-сессии х, обладающей ролью или административной ролью, имеющей право доступа 
владения к сущности или субъект-сессии у, а также не обладающей запрещающей ролью, 
имеющей это право доступа к у, добавить или удалить у запрещающей роли пг (к которой 
субъект-сессия х должна иметь административный доступ на запись) право доступа владения 


к у. При этом запрещающая роль не становится ролью-«владельцем» или ролью 
'“антивладельцем” сущности или субъект-сессии у, допускается, что запрещающих ролей, 
обладающих правом доступа владения к сущности или субъект-сессии может быть 
несколько. С этим связано неиспользование для этого правила вида зеі_епІіІу_о\/ѵпег(х, г,г’,у) 
и зеІ_зиЬіесІ_о\А/пег(х,г,г’,у). 

Де-юре правила вида дгапІ_асІтіп_гідМІ5(х, аг, {(г, ар): 1< \ < к}) и 

гетоѵе_асІтіп_гідИІ5(х,аг,{(г, ап): 1< і < к}) позволяют субъект-сессии х добавить или удалить 
соответственно, права доступа на чтение или запись к роли, запрещающей роли или 
административной роли г из множества прав доступа административной роли аг, к которой х 
должна иметь административный доступ на запись. Для изменения прав доступа к роли г 
требуется наличие у х текущей административной роли гоІез_асІтіп_гоІе, если г является у х 
текущей административной роли гоІез_асІтіп_гоІе, а если административной ролью, то 
административной роли педаІіѵе_гоІез_асІтіп_гоІе. При удалении административных прав 
доступа не должны нарушаться заданные предположении 2.2 требования к правам доступа 
индивидуальных административных ролей, индивидуальных ролей учетных записей 
пользователей и общей роли, а также если удаляется право доступа на чтение к 
запрещающей роли, то она или какая-либо подчиненная ей роль не должны быть заданы для 
индивидуальной административной роли, индивидуальной роли некоторой учетной записи 
пользователя или общей роли, когда административная роль аг является индивидуальной 
ролью этой учетной записи пользователя. 

Де-юре правила вида асісІ_педаІіѵе_гоІе(х,г,пг) и гетоѵе_педаІіѵе_гоІе(х,г,пг) 
позволяют субъект-сессии х добавить или удалить соответственно, для роли или 
административной роли г запрещающую роль пг. Для этого субъекта-сессия х должна 
обладать текущей специальной административной ролью педаІіѵе_гоІез_асІтіп_гоІе, а также 

соответственно либо специальной административной ролью гоіез _ асітіп _ гоіе, либо 

асІтіп_гоІез_асІтіп_гоІе. При этом нельзя задавать запрещающие роли для любых 
специальных административных ролей из множества ЗАВ, и для упрощения 
администрирования системы при добавлении запрещающей роли для роли или 
административной роли г ни одна субъект-сессия не должна иметь к ней административных 
доступов на чтение. 

Де-юре правила вида сгеаІе_оЬіесІ(х,у,усІ,папле, 2 ), сгеаІе_сопІаіпег(х,у,усІ,папле, 2 ) и 
сІеІеІе_епШу(х,у, 2 ) позволяют субъект-сессии х создать или удалить сущность-объект или 
сущность-контейнер у, входящую в состав сущности-контейнера 2 , к которой субъект-сессия 
х должна иметь доступ на запись и обладать текущей ролью или административной ролью, 
имеющей к 2 право доступа на выполнение ехесиіег, и одновременно не обладать текущей 
запрещающей ролью, имеющей к 2 это право доступа. В соответствии со спецификой 



файловой системы ОССН нельзя создавать одноименные сущности в одной сущности- 
контейнере или удалять непустые сущности-контейнеры (удаление таких сущностей- 
контейнеров реализуется в ОССН рекурсивно, с использованием удаления сущностей- 
объектов и пустых сущностей-контейнеров), а при удалении сущности объекта должно быть 
проверено отсутствие на него других “жестких” ссылок. 

Де-юре правила вида сгеаіе_кіагд_Ііпк(х, у, пате, г) и сІеІеіе_ІіагсІ_Ііпк(х, у, пате, г) 
позволяют субъект-сессии х создать или удалить соответственно, в составе сущности- 
контейнера 2 (к которой субъект-сессия х должна иметь доступ на запись и обладать текущей 
ролью или административной ролью, имеющей к вправо доступа на выполнение ехесиіег, и 
одновременно не обладать текущей запрещающей ролью, имеющей к г это право доступа) 
«жёсткую» ссылку на сущность-объект у. При создании «жёсткой» ссылки на сущность у 
учитываются права доступа к сущностям-контейнерам, ее содержащим. Так как в ОС 
семейства Ипих возможно создание в одной сущности-контейнере нескольких «жёстких» 
ссылок (с разными именами) на одну сущность-объект, то в условиях применения правила 
сгеаіе_ІіагсІ.Ііпкне требуется отсутствие сущности-объекта у в составе сущности-контейнера 
2 , а в правиле с!еІеіе_ІіагсІ_Ііпк указывают имя «жёсткой» ссылки, с которым она будет 
удалена. Поскольку «жёсткие» ссылки создаются только на объекты, то не требуются 
проверки на появление циклов в иерархии сущностей. При создании «жёсткой» ссылки 
учитывается вид её метки, в результате, если у сущности у метка прямая, то она прямая у 
сущности-контейнера 2 , а если у сущности у метка косвенная, то “жесткая” ссылка на нее 
может быть осуществлена только когда сущность контейнера 2 подчинена в иерархии 
единственной удовлетворяющей условию 8 предположения 2.2 сущности-контейнеру с 
прямой меткой старшей в иерархии х и у. При удалении проверяется, действительно ли 
удаляется “жесткая” ссылка (т.е. есть еще другие ссылки на нее), и учитывается, 
осуществляется ли удаление “жесткой” ссылки в разделяемой сущности-объекта и “жесткой” 
ссылки на него реализуется, как правило, одной функцией. В то же время, так как формально 
результаты таких удалений существенно отличаются, то для удобства в рамках модели 
заданы два правила. 

Де-юре правила вида гепате_епШу(х,у, оІсІ_пате, пате, г) и пате_гоІе(х, гу, пате) 
позволяют субъект-сессии х переименовать сущность у, входящую в состав сущности- 
контейнера 2 , к которой субъект-сессия х должна иметь доступ на запись и обладать текущей 
ролью или административной ролью, имеющей к ней право доступа на выполнение ехесиіе г , 
и одновременно не обладать текущей запрещающей ролью, имеющей к г это право доступа, 
или соответственно переименовать роль, запрещающую роль или административную роль гу 
во всех ролях-контейнерах, в которые она входит (так как каждая роль, запрещающая роль 
или административная роль имеет в отличие от сущностей уникальное имя), и х которым 



субъект-сессия х должна иметь административные добуду на запись. Поскольку на сущность- 
объект может быть несколько «жёстких» ссылок в одной сущности-контейнере и, следо¬ 
вательно, несколько имён, то в правило добавлен параметр, указывающей старое имя 
сущности, подлежащее замене. Для ролей такой параметр не требуется, так как роль должна 
иметь в системе уникальное имя. Правило переименования роли не использовалось в 
предыдущих ДП-моделях и включено в МРОСЛ ДП-модель с учётом реализованного в ней 
представления ролей как аналогов сущностей-контейнеров. В связи с этим для 
переименования роли, запрещающей роли или административной роли требуется наличие у 
субъект-сессии доступа на чтение к административной роли гоІез_асІтіп_гоІе, 
педаІіѵе_гоІез_асІтіп_гоІе или адтіп_гоІе_.ас1тіп_гоІе соответственно, при этом нельзя 
переименовывать роли, являющиеся индивидуальными ролями и индивидуальными 
административными ролями учётных записей пользователей, а также общей Ролью и 
специальными административными ролями из множества ЗАР. При переименовании 
сущности учитывается, осуществляется ли одно в разделяемой сущности-контейнере 7. или 
нет. 

Де-юре правило вида геасі_сопіатпег(х, у, г) позволяет субъекту-сессии х «считать» в 
сущность-объект т. (например, в ОССН в сущности “Рабочий стол”), к которой она должна 
иметь доступ на запись, содержимое (имена входящих в неё непосредственно сущностей или 
ролей) сущности-контейнера, роли, запрещающей роли или административной роли у, к 
которой х должна иметь через соответствующую роль или административную роль права 
доступа на чтение и выполнение, с учетом прав доступа к сущностям-контейнерам, 
содержащим у, а так же не иметь текущих запрещающих ролей, обладающих к у правами 
доступа на чтение или на выполнение. 

Де-юре правило вида деі_епіііу_аііг(х,у,і), де1__зиЬ]ес1_айг(х,у,х) и деі_го!е_аШ(х,у,і), 
позволяют субъект-сессии х “считать” в сущности-объекта 2 , к которой она должна иметь 
доступ на запись, атрибуты сущности, субъекты-сессии, роли, запрещающие роли или 
административные роли у соответственно. В случае, когда уявляется сущностью, требуется, 
чтобы субъект-сессия х могла получить к ней доступ с учетом прав доступа х к сущности- 
контейнерам, содержащим у. А в тех случаях, когда для предоставления параметров 
сущности или субъект-сессии х текущей роли, обладающей к у правом доступа владения, 
дополнительно требуется отсутствие у х текущей запрещающей роли, обладающей к у 
правом доступа владения. 

Для сущности у выдаются следующие атрибуты: 

• вид метки; 

• для сущности-контейнера является ли она разделяемой; 

• для сущности-объекта число «жёстких» ссылок на неё; 



• роли, запрещающие роли или административные роли и имеющиеся у них права 
доступа к сущности (в случае, когда х имеет административный доступ на чтение либо к роли- 
«владельцу» сущности у, либо к административной роли еп1Шез-асІтіп,гоІе)- Для субъект- 
сессии у выдаются следующие атрибуты: 

• учётная запись пользователя, от имени которой она функционирует; 

• роль-“владелец” субъект-сессии (в случае, когда х имеет административный доступ на 
чтение либо к роли-“владельцу” субъект-сессии у, либо к административной роли 
зиЬіесіз_асІтіп_гоІе), а также запрещающие роли, имеющие права доступа владения к 
субъект-сессии; 

• текущие административные доступы субъект-сессии к ролям, запрещающим ролям или 
административным ролям (в случае, когда х имеет административный доступ на чтение либо 
к роли-“владельцу” субъект-сессии у, либо к административной роли зиЬ]ес1з_асІтіп_гоІе)] 

• вид метки (всегда Ігие); 

• является ли она разделяемой (всегда Ігие, выдается для общности формата данных с 
аналогичными данными для сущностей); 

• число «жёстких» ссылок на роль, запрещающую роль или административную роль (в 
случае, когда х имеет административный доступ на чтение административной роли 
гоІез_асІтіп_гоІе, педаііѵе_гоІез_асІтіп_гоІе или асІтіп_гоІез_асІтіп_гоІе соответственно); 

• административные роли и имеющиеся у них права доступа к роди, запрещающей роли 
или административной роли у (в случае когда х имеет административный доступ на чтение к 
административной роли гоІез_асІтіп_гоІе, педаііие_гоІез_асІтіп_гоІе или 
адтіп_гоІез_асІтіп_гоіе, соответственно); 

• значение функции сопзігаіп^н — для роли и административной роли, заданные для 
неё запрещающие роли, для запрещающей роли — роли или административные роли, для 
которых она таковой является (в случае, когда х имеет административный доступ на чтение 
к административной роли педаііѵе_гоІез_асІтіп_гоІе). 

Де-юре правило вида зеІ_сопІаіпег_аПг(х, у, I) позволяет субъект-сессии х задать 
сущности-контейнеру у является ли она разделяемой или нет. При этом субъект-сессия х 
должна иметь либо административный доступ на чтение к роли-«владельцу» контейнера у и 
не иметь текущей запрещающей роли, обладающей правом доступа владения к у, либо иметь 
административный доступ на чтение к административной роли епііііез_асІтіп_гоІе, а также 
требуется, чтобы доступ к у мог быть предоставлен х с учётом её прав доступа к сущностям- 
контейнерам, содержащим у. 

Де-юре правило вида сгеаі_Лгзі_зиЬ]ес1(х, и, у, г) позволяет субъект-сессии х с 
использованием сущности у и учётной записи пользователя и создать от имени и новую 
субъект-сессию г. Для этого требуется наличие у субъект-сессии х доступа на чтение к роли 



обладающей правом доступа на выполнение к сущности у (к которой субъект-сессия х может 
получить доступ с учётом прав доступа к сущностям-контейнерам, содержащим сущность у), 
и отсутствием у х текущей запрещающей роли, обладающей правом доступа выполнение к у. 
После создания субъект-сессии г она (в отличии от предшествующих ДП-моделей) получает 
доступы на запись и чтение к индивидуальной роли и_с и общей роли соттоп_гоІе, и доступ 
на чтение к индивидуальной административной роли и_ас!тіп. При этом индивидуальная 
роль и_с получает право доступа владе ния к субъект-сессии 2 .Кроме того, для того чтобы 
создаваемая субъект-сессия г могла получить в качестве текущих все запрещающие роли 
для индивидуальной административной роли, индивидуальной роли её учетной записи 
пользователя и для общей роли, проверяется наличие права доступа на чтение ко всем таким 
запрещающим ролям у индивидуальной административной роли учетной записи 
пользователя субъект-сессии 2 получает административный доступ на чтение ко всем этим 
запрещающим ролям. 

Дю-юре правила вида сгеа1е_зиЬ}вс1(х,у,г) и с!еІеіе_зиЬіесі(х, х)позвопяют субъект-сессии х 
создать или удалить, соответственно, субъект-сессию 2 . При создании требуется наличие у 
субъект-сессии х доступа на чтение к роли, обладающей правом доступа на выполнения к 
сущности у (к которой субъект-сессия х может получить доступ с учетом прав доступа к 
сущностям-контейнерам, содержащим сущность у), и отсутствие х у текущей запрещающей 
роли, обладающей правом доступа на выполнение к у. После создания субъект-сессии 2 она 
получает доступы на запись и чтение к индивидуальной роли изег(х)_с и общей роли 
соттоп_гоІе, и доступа на чтение к индивидуальной административной роли изег(х)_адтіп, 
соответствующим её учётной записи пользователя (у субъект-сессий х и у ,общая учётная 
запись пользователя), и непосредственно подчиняется в иерархии субъект-сессии х. При 
этом индивидуальная роль изег(х)_с получает право доступа владения к субъект-сессии 2 . 
Аналогично предыдущему де-юре правилу проверяется наличие права доступа на чтение ко 
всем: соответствующим запрещающим ролям у индивидуальной административной роли 
учётной записи пользователя субъект-сессии х. После применения правил созданная 
субъект-сессии 2 получает административный доступ на чтение ко всем этим запрещающим 
ролям. При удалении субъект-сессии г требуется, чтобы ее в иерархии не подчинялись 
другие субъект-сессии (в противном случае удаление надо начинать с них), и требуется 
наличие у субъект-сессии х доступа на чтение х роли-«владелыду» (обладающей правом 
доступа владения) субъект-сессии 2 , а также отсутствие у х текущей запрещающей роли, 
обладающей правом доступа владения к 2 . 

С целью дальнейшего формального обоснования свойств систем, построенных в рамках 
МРОСЛ ДП-модели, целесообразно доказать, что условия и результаты правил 
преобразования состояний систем заданы корректно, то есть соответствуют предположению 



2.2. При этом с учетом особенностей задания этого предположения требуется доказать, что 
его условия выполняются как в состояниях на траекториях функционирования системы, так и 
при переходах между состояниями. 

Утверждения 2.1. Пусть Ѳо-начальное состояние системы І(0’,ОР,Оо), удовлетворяющее 
условиям предположения 2.2. Тогда для любой траектории <Зо-ор1 01-ор2 Оп,где /V > 1,в 
состоянии Оп выполняются условия предложения 2.2,а также переход Оп-1 орп Оп 
удовлетворяет условиям этого предположения. 

Доказательство этого утверждения осуществляется аналогично доказательству 
соответствующего утверждения для уровня ролевого доступом, изложенному в [33]. 

2.2.4. Подходы к моделированию ролевого управления доступом в СУБД РозідгеЗОІ- 
СУБД Р озІдгеЗОІ- является основной из применяемых на базе ОССН, механизмы управления 
доступа которой поэтапно интегрируется с соответствующими механизмами ОССН, что в 
перспективе создает предпосылки для противодействия запрещённым информационным . 
потокам по памяти и по времени, возникающим при взаимодействии компонент СУБД и ОССН 
между собой. По этой причине в рамках иерархического представления МРОСЛ ДП-модели 
разработаны уровни для СУБД Р озІдгеЗОІ- [24], «опирающиеся» на соответствующие уровни 
для ОССН (см. рис. 2.1). 

Вместе с тем основанный на стандарте $0/. механизм управления доступом в СУБД, имеет 
ряд существенных отличий от аналогичного механизма ОССН, он гораздо сложнее поддаётся 
модификации. Поэтому при его моделировании в отличие от [70, 71, 91] не учитывается 
многие детали его реализации, так как это затруднит разработку подходов по 
противодействию запрещённым информационным потокам по времени или потребует 
использования для их применения существенных ресурсов СУБД, что может негативно 
сказаться на ее производительности. 

В результате на уровне ролевого управления доступом СУБД Р озІдгеЗОІ- МРОСЛ ДП-модели 
использованы: 

• множества: ролей СУБД, административных привилегий СУБД 

(ЗІІРЕРІІЗЕР, СРЕА ТЕПОІ-Е, СРЕА ТЕОВ, І.06//Ѵ, РЕРІЕСА 770Л/, /Л/ЯЕЯ/Г),административны 
х ролей СУБД, специальных ролей СУБД, общих ролей СУБД, элементов СУБД, элементов- 
объектов СУБД(каталоги по событию, расширения, сопоставления, домены, конфигурации, 
словари, парсеры, шаблоны, функции, последовательности, строки, ограничения, индексы, 
правила, триггеры, триггерные функции, репликации),элементов-контейнеров СУБД 
(кластеры, базы данных, схем , таблицы , столбцы, представления , табличные 
пространства), видов привилегий СУБД (5Е/.ЕС7", /Л/8ЕЯТ, РйАТЕ, ОЕ/.ЕТЕ, ТРІІМСАТЕ, 
ЯЕЕЕЯЕЛ/СЕ, ТРІввЕР, ІІЗАОЕ, СРЕАТЕ, СОМ МЕСТ, ТЕМРОРАРУ, ТЕМР, ЕХЕССТЕ, 
01/1/Л/), сущностей СУБД (на этом уровне модели сущностями являются элементы СУБД от ее 



схем и далее выше по иерархии, например, базы данных, кластеры), привилегий к элементам 
СУБД; 

• функции: административных привилегий ролей СУБД ролей, входа субъект-сессий в СУБД, 
наследования привилегий ролей к элементам СУБД, управления подчинённостью ролей в 
иерархии, административных прав доступа административных ролей ОССН и СУБД к ролям 
СУБД, привилегий к элементам СУБД ролей СУБД, соответствия административных 
привилегий и видов привилегий к элементам СУБД правам доступа, эффективных прав 
доступа ролей СУБД. 

Кроме того, переопределены: 

• множество доступов субъект-сессий к ролям, запрещающим ролям, административным 
ролям или ролям СУБД; 

• функции: имён сущностей и элементов СУБД, имён ролей, запрещающих ролей, 
административных ролей, ролей СУБД, доступа субъект-сессий к сущностям или элементам 
СУБД в контейнерах; 

• иерархия сущностей и элементов СУБД; 

• иерархия ролей, запрещающих ролей, административных ролей и ролей СУБД; 

• состояние системы. 

Сформулированы несколько десятков условий, которым должно удовлетворять единое 
ролевое управление доступом в СУБД и ОССН, в том числе определяющих порядок: 

• использования административных прав доступа, привилегий ролей и специальных 
административных ролей СУБД; 

• создания, удаления, изменения иерархии ролей СУБД; 

• администрирования иерархии сущностей и элементов СУБД; 

• управления доступом к сущностям СУБД; 

• использование административных доступов субъект-сессий к ролям СУБД. 

При этом по аналогии с уровнями модели для ОССН описание условий, касающихся порядка 
реализации в СУБД мандатного контроля целостности и мандатного управления доступом, 
осуществлено на последующих соответствующих уровнях модели. 

На уровне ролевого управления доступом СУБД Р озІдгеЗОІ- иерархического представления 
МРОСЛ ДП-модели по сравнению с уровнем ролевого управления доступом для ОССН не 
было задано новых де-юре правил преобразования состояний, их осталось 35, хотя большая 
их часть была существенно модифицирована путем добавления в правила новых 
параметров, условий и результатов применения , учитывающих специфику управления 
доступом в СУБД.В итоге сформулировано и обосновано утверждение (аналогичное 
утверждению 2.1) о соответствии (корректности) правил преобразования состояний системы 



заданным на этом уровне модели условиям, которым должно удовлетворять ролевое 
управление доступом. 

Таким образом, удалось разработать и апробировать подходы х моделированию ролевого 
управления доступом в СУБД, Р озІдгеЗОІ-, совместимые с использованными при 
формировании иерархического представления МРОСЛ ДП-модели, изначально 
предназначавшегося для моделирования безопасности мандатного и ролевого управления 
доступом, мандатного контроля целостности в ОССН. Это создаёт предпосылки для 
дальнейшего использования этих видов управления доступом при развитии модели 
управления доступом в СУБД, её верификации с использованием инструментальных средств, 
практической реализации единого механизма управления тупом в ОССН и СУВА, а также 
сертификации СУБД Р озІдгеЗОі- на соответствии требованиям высоких уровней доверия [83]. 

2.3. Уровень мандатного контроля целостности 
2.3.1. Элементы состояния системы 

Рассмотрим основные элементы, вводимые на уровне мандатного контроля целостности 
МРОСЛ ДП-модели. Используем следующее предположение. 

Предположение 2.3. Каждая учётная запись пользователя является учётной записью 
либо доверенного, либо недоверенного пользователя. Каждая субъект-сессия является 
либо доверенной,либо недоверенной.От имени учетных записей недоверенных 
пользователей могут функционировать только недовренные субъект-сессии. 

Здесь и далее использован классический для теории моделирования безопасности 
управления доступом подход, заключающийся в следующем. Как правило, предполагается, 
что проверка безопасности системы должна осуществляться после того, как доверенные 
(привилегированные, административные субъект-сессии, являющиеся частью под 
безопасности, чью функциональность можно верифицировать) субъект-сессий выполнили 
свои задачи по изменению параметров функционирования системы, в том числе по передаче 
прав доступа или созданию новых доверенных субъект-сессий. При этом требуется 
удостоверяться, что дальнейшее функционирование системы под воздействием 
недоверенных (от имени учётных записей непривилегированных пользователей, часто 
рассматриваемых как нарушители) субъект-сессий будет безопасным, т.е. не приведёт к 
несанкционированной передаче прав доступа или созданию 

запрещённых информационных потоков. Однако для более полного описания требований к 
реализации управления доступом в ОССН в модель будут включены элементы, 
используемые для администрирования ОССН доверенными субъект-сессиями. 

Используем следующие обозначения: 

Иі={\л/гііе т/-множество видов информационных потоков (при обеспечении целостности 
рассматриваются только информационные потоки по памяти); 



Е<(Е и 5) х (Е и 5) х Ні- множество информационных потоков; 

(И, <)-решетка уровней целостности данных, при этом заданы минимальной і_Іоѵѵ=+и и 
максимальный і_ііідіі=+и элементы решетки соответственно; 

( іи,іс,іг,із ) 6 I- четвёрка функций уровней целостности, при этом: 

іиіСІ-І-І функция, задающая для каждой учётной записи пользователя её уровень целостности 
— максимальный разрешённый уровень целостности субъект-сессий, функционирующих от 
ее имени; 

іе:ІІ-І-І функция, задающая уровень целостности для каждой сущности; 

іг:Н и Л/Я и АН - /./-функция, задающая для каждой роли, запрещающей роли или 

административной её уровень целостности; 

/5/ 5-Ы- функция, задающая для каждой субъект-сессий ее текущий уровень целостности; 
/-множество всех четверок функций заданного вида; 

ССНІ:Е и Я и Л/Я и АН-{ігие,іаІзе}-фунщ\ля, задающая способ доступа к сущностям внутри 
контейнеров, ролям, запрещающим или административным ролям в иерархии ролей (с 
учетом их мандатных уровней целостностей). Если сущность е ЕС является контейнером и 
доступом сущностям, содержащимся внутри контейнера е, разрешен без учета уровня 
целостности контейнера Е, то по определению выполняется равенство ССНІ(е) = іаізе, в 
противном случае выполняется равенство ССНІ(е) = Ігие. При этом по определению для 
каждой сущности объекта о Е О выполняется равенство ССНІ(о) = ігие. При этом для ролей, 
запрещающих ролей административных ролей г е Я ІІ Л/Я ІІ АН выполняется равенство 
ССНІ(г) = іаізе. 

Реализация мандатного контроля целостности целесообразно в современных 
защищённых ОС. Такой механизмы (МІС- Мапсіаіогу Іпіедгііу СопігоІ и 1)АС — ІІзег Ассоипі 
СопігоІ) в ОС семейства Місгозоіі 1/1 /іпсіоѵѵз Ѵізіа/7/2008 [108] позволил существенно повысить 
их защищенность. С его применением все учётные записи пользователей, субъект-сессии, 
сущности и роли чётко разделяются на два непересекающихся множества — влияющих на 
целостность и безопасность ОССН (соответствующих, например, уровню целостности і_ііідіі) 
или нет (соответствующих, например, уровню целостности і_Іоѵѵ). Преимущества мандатного 
контроля целостности аналогичны преимуществам мандатного управления доступом в 
сравнении 

с дискреционным управлением доступом, т.е. обеспечивается большая ясность правил 
разделения компонент системы на критичные и некритичные с точки зрения её целостности, 
тем самым снижается риски ощибок. 

В мандатном управлении доступом решётка многоуровневой безопасности содержит 
достаточно много элементов (за счёт наличия неиерархических категорий), при этом 
требуется противодействие запрещенным информационным потокам по времени. Таким 



образом, для обеспечения большей надёжности мандатное управление доступом 
целесообразно в дальнейшем реализовывать в модели раздельно от ролевого управления 
доступом. Иначе потребовалось бы задание сложной ролевой иерархии с разделением 
ролей, как минимум , на «роли на чтение» и «роли на запись» (например, как в мандатной 
модели РВАС [17, 134]). При этом пользователям будет достаточно сложно выбирать 
необходимый набор ролей и корректно их администрировать. Для мандатного контроля 
целостности достаточно меньшего числа уровней и его задание с помощью ролей может 
оказаться более понятным для пользователей и администраторов ОССН, кроме того, 
требуемый для пользователя уровень целостности (уровень целостности субъект-сессий, 
функционирующих от имени его учетной записи) непосредственно зависит от выполняемой 
пользователем функции (роли) в защищенной ОССН. При этом в большинстве случаев 
пользователи будут тать в ОССН, используя только низкий (минимальный) уровень 
целостности (вне зависимости от текущего уровня доступа манда,, управления доступом), а 
высокий уровень целостности (или уровень выше минимального) будет необходим только 
при выполнении административных или системных функций. Мандатные атрибуты 
целостности ССНІ используются аналогично мандатным атрибутам конфиденциальности 
сущностей-контейнеров ССНР ( Сопіаіпег СІеагапсе Яедш'гес/), наследованным из модели 
систем военных сообщений (СВС) [17, 121]. В качестве источников и приёмников 
информационных потоков по памяти на уровне мандатного контроля целостности 
рассматриваются только сущности и субъект-сессии, так как роли, запрещающие роли или 
административные (что будет учтено в перспективе) могут использоваться только для 
созданы информационных потоков по времени. 

Для отражения этих изменений на текущем уровне модели в функции ехесиІе_сопІаіпег 
дополняется одно из её условий: 

Условие 3. Существует гі е Р и АН такая, что (з,г1,геад) е е АА и (сі ехесиіе) е РА (гі),ве рно 
іе(еі) < із(з) или ССНІ (еі)= іаізе, где 1 < / < п. 

Определение 2.5. Пусть определены множество информационных потоков Р и функции 
уровней целостности (іи, іе, іг, із) и мандатных атрибутов целостности ОСИП. Переопределим 
С = = (АРА, РА, изег, (іи, іе, іг, із), ССРІ, А, АА, Р, Нг, Не,Нз, сопзігаіпіпг) — состояние системы. 
Предположение 2.4. В рамках МРОСЛ ДП-модели новь» значения для функции задаются 
только при создании соответствующих новых субъект-сессий. В начальном состоянии Со 
любой системы I (С*, ОР, Со) для любых субъект-сессии 5 е Во и сущности е е Ео,е ели 
(з,е,а) е /4о,где а е Ра,то существеует контейнер с е Со и справедливо равенство 
ехеси1е_соп1аіпег0(з,с,е)=1гие. 

В предложении требуется, чтобы в начальном состоянии доступы субъект-сессии к 
сущностям соответствовали мандатному контролю целостности. Кроме того, по сравнению 



с предшествующим ДП-модели в рамках МРОСЛ ДП-модели допускается 
администрирование существенных параметров системы , влияющих на ее безопасность 
(множество учетных записей пользователей, ролей, запрещающих ролей или 
административных ролей, значений уровней целостности четных записей пользователей и 
сущностей). Это целесообразно для строгого задания соответствующих правил 
преобразования состояний системы, ориентированных на реализацию в ОССН. Однако для 
сохранения преемственности с классическим подходом в дальнейшем планируется показать 
целесообразность рассмотрения при анализе безопасности системы только таких траекторий 
её функционирования, на которых данные «административные» правила не будут 
использоваться. 

2.3.2. Функционально или параметрически ассоциированные сущности 

Сформулируем предположения, позволяющие учесть наличие в ОССН сущностей, 
функционально или параметрически ассоциированных с учётными записями пользователей, 
субъект-сессиями или ролями. 

Предположение 2.5. Для каждой учётной записи пользователя задаётся множество 
сущностей, параметрически с ней ассоциированных, получение доступов на чтение или на 
запись к которым субъект-сессией необходимо для того, чтобы создать субъект-сессию от 
имени данной учётной записи пользователя. Множество сущностей, параметрически 
ассоциированных с учётной записью пользователя не изменяется в ‘процессе 
функционирования системы. 

Примерами параметрически ассоциированных сущностей с учётными записями 
пользователей являются файлы паролей, соокіез или ключей и т.д., т.е. «знание» чего 
(получение к ним доступа на чтение) или «подмена чего (получение к ним доступа на запись) 
позволяет недоверенной субъект-сессии создать в системе субъект-сессию от имени данной 
учётной записи пользователя. При реализации ОССН необходимо иметь возможность для 
каждой учётной записи пользователя чётко описывать множество всех параметрически 
ассоциированных с нею сущностей, т.е. может потребоваться некоторая методика, возможно, 
автоматизированная в ПО, осуществляющем формирование множества параметрически 
ассоциированных сущностей для каждой учётной записи, пользователя. 

Предположение 2.6. Параметрически ассоциированными сущностями с субъект-сессией 
являются сущности, которые содержат данные, позволяющие захватить управление 
(контроль) над нею. Множество сущностей, параметрически ассоциированных с субъект- 
сессией, задается в момент ее создания только в зависимости от сущности, из которой 
создается данная субъект-сессия, и учетной записи пользователя, от имени которой другая 
субъект-сессия создает данную субъект-сессию. 



Примерами параметрически ассоциированных сущностей с субъект-сессии являются 
файлами соокіез. «Знание» таких сущностей (получение от них информационного потока по 
памяти) позволяет недоваренной субъект-сессии «выдать» себя за другую субъект-сессию 
(получить над нею контроль). В ОССН наличие у субъект-сессий параметрически 
ассоциированных сущностей достаточно редкое явление. Как правило, такие сущности есть 
у приложений, осуществляющих удалённый доступ к чему-либо, или у криптографических 
приложений, которым нужны соответствующие ключи. При реализации ОССН необходимо 
иметь возможность (соответствующую методику, ПО) для каждой субъект-сессии чётко 
описывать множество всех параметрически ассоциированных с нею сущностей. 
Предположение 2.7. Функционально ассоциированными с субъект-сессией являются 
сущности, от которых зависит преобразование данных (функциональность), реализуемое 
субъект-сессией. Только информационный поток по памяти к сущности, функционально 
ассоциированной с субъект-сессией, приводит к изменению преобразования данных, 
реализуемого этой субъект-сессией, и позволяет захватить над нею управление (контроль). 
Множество сущностей, функционально ассоциированных с субъект-сессией, задается пря 
создании субъект-сессии. При создании новой субъект-сессий .множество функционально 
ассоциированных с ней сущностей задаётся только в зависимости от сущности, из которой 
создаётся данная субъект-сессия, и учётной записи пользователя, от имени которой другая 
субъект-сессия создает данную субъектную-сессию. 

Примерами функционально ассоциированных сущностей являются исполняемые файлы, 
файлы динамических библиотек, конфигурационные файлы, сегменты памяти, в которых 
размещается исполняемый код, стек и т.д. Таким образом, запись в эти сущности может 
позволить изменить функциональность субъект-сессии, поставить ее “под контроль” другой 
субъект-сессии. Описание всех функционально ассоциированных с субъект-сессией 
сущностей является задачей более сложной, чем описание параметрически 
ассоциированных сущностей, так как в ОССН достаточно трудно для каждой субъект-сессии 
в отдельности описывать в точности все, от чего зависит ее функциональность. Поэтому при 
реализации ОССН необходимо иметь возможность (соответствующим методику, ПО) для 
каждой субъект-сессии, возможно, с некоторой избыточностью описывать множество ее 
функционально ассоциированных сущностей, а любой компромисс здесь( пример, 
невключение сущности в соответствующее множество) должен быть обоснован как часть 
политики безопасности системы. 

Предположение 2.8. Для каждой роли, запрещающей роли или административной роли 
задается (возможно, пустое) множество сущностей, параметрически с ней ассоциированных. 
При этом для получения или удаления субъект-сессией доступа к роли кроме наличия к 
данной роли соответствующего права доступа, этой субъект-сессией необходимо получить 



доступ на чтение или на запись ко всем сущностям, параметрически ассоциированным с 
данной ролью. Множество сущностей , параметрически ассоциированных хотя бы с одной 
ролью, запрещающей ролью или административной ролью, не изменяется в процессе 
функционирования системы. 

Примерами параметрически ассоциированных сущностей с ролями являются файлы 
паролей, файлов ключей. Лишь у небольшого числа ролей могут быть такие сущности, их 
наличие позволяет обеспечить дополнительную защиту при получении субъект-сессией 
доступа к роли, например, потребовав дополнительно повторно ввести пароль. При 
реализации ОССН необходимо иметь возможность (соответствующую методику, ПО) для 
каждой роли чётко описывать множество всех параметрически ассоциированных с нею 
сущностей. Поскольку все роли субъект-сессии получают через индивидуальные 
административные роли их учётных записей пользователей, то требуется совпадение 
соответствующих множеств параметрически ассоциированных сущностей с 
индивидуальными административными ролями и учётными записями пользователей. 

С учетом сделанных предположений и замечаний используем следующие обозначения: 

/и/ е Е - множество сущностей, параметрически ассоциированных с учетной записью 
пользователя и е II (здесь используется предположение 2.5); 

ІІЕ = {е Е ]и[: и Е I)} - множество сущностей, каждая из которых параметрически 
ассоциирована хотя бы с одной учетной записью пользователя; 

|з| 6 Е - множество сущностей, параметрически ассоциированных с субъект-сессией 5^5; 
Ер: і! х Е - 2 Л Е - функция , задающая множества сущностей, параметрически 
ассоциированных с субъект-сессией при ее создании из сущности от имени учетной записи 
пользователя. При этом если из сущности е Е Е от имени учетной записи пользователя и Е і! 
невозможно создать новую субъект-сессию, то по определению справедливо равенство 
Гр(и,е) = 0; 

[з] с Е- множество сущностей, функционально ассоциированных с субъект-сессией з; 

Іа.іІ х Е- 2е-функция задающие от множества сущностей, функционально ассоциированных 
с субъект-сессией при ее создании от имени учётной записи пользователя из сущности.При 
этом если из сущности е Е Е от имени учётной записи пользователя и Е і! невозможно 
создать новую субъект-сессию, то по определению справедливо равенство іа(и,е)=0. Кроме 
того ,по определению выполняется условие: для каждой субъект-сессии 5^5 существует 
единственная сущность е Е Е такая, что справедливы равенства ір(изег(з)ез)=]з[ и 
іа(изег(з)ез)=[з] (здесь используется предложение предположение 2.7) 

]г[с Е- множество сущности параметрически ассоциированных с ролью, запрещающей ролью 
или административной ролью ге Н и NН и АН (здесь используется предположение 2.8.) 



ЯЕ={е Е ]г[: г Е Я и Л/Я и АЯ}- множество сущностей, параметрически ассоциированных хотя 
бы с одной ролью, запрещающей ролью или административной ролью. 

2.3.3. Условия корректности мандатного контроля 
целостности для состояний системы 

Для задания мандатного контроля целостности для элементов состояний системы 
используем следующее предположение. 

Предположение 2.9. В системе на уровне мандатного контроля целостности МРОСП ДП- 
модели выполняются следующие условия. 

Условие 1 (текущий уровень целостности субъект-сессии): 

• учётные записи доверенных пользователей имеют высокий уровень целостности і_ііідіі, а 
недоверенных пользователей — меньший і_іііді 7 (например, і_Іоѵѵ), при этом используем 
следующие обозначения: Ш = {и Е II: іи(и) = ЦпідМ} — множество учётных записей 
доверенных пользователей, Ми = {и Е II: іи(и) « і_Мдф — множество учётных записей 
недоверенных пользователей; 

• текущий уровень целостности субъект-сессии не превосходит уровня целостности учётной 
записи пользователя, от имени которой она функционирует: для субъект-сессии з ^5 верно 
неравенство із(з) <<іи(изег(з)), при этом используем следующие обозначения:І_з={5 Е 
5.7з('з,)=/_/7/д/7/-множество доверенных субъект-сессий,Мз={з Е 3:із(з)< і_іііді ^-множество 
надоверенных субъект-сессий, по определению выполняется следующее условие: если для 
субъекта-сессии з еЗ верно із(з)=і_ЫдМ,то изег(з) е іи (высокий уровень целостности могут 
иметь только субъект- сессии функционирующие от имени учетной записи доверенных 
пользователей); 

• текущий уровень целостности субъекта и не превосходит текущего уровня целостности 
субъект-сессии, которой она подчинена в иерархии: для субъект-сессии з, з' С 8, если з < з', 
то /з(з) < із(з’). 

Условия 2 ( уровень целостности сущности, вид метки): 

• уровень целостности сущности, входящей в состав сущности-контейнера, не превосходит 
уровня целостности сущности-контейнера: для сущностей е,е’С Е, если е < е\ то іе(е) < іе(е’); 

• мандатный атрибут целостности ССІЧІ каждой сущности с косвенной меткой равен Ігие, ее 
уровень целостности равен уровню целостности соответствующей единственной по условию 
8 предложения 2.2 сущности-контейнера: для каждой сущности е С Е такой, что сіігесі(е) = 
1 аізе , существует единственная сущность-контейнер с С С такая, что сіігесі(с) = ігие, е меньше 
с и для любой сущности е’ С Е такой, что е’ меньше с, выполняется іе(е’) = іе(с) и СЯЯІ(е’) = 
ігие. 

Условия 3 (уровень целостности роли, запрещающий роли или административной роли): 



• уровень целостности роли , запрещающей роли или административной роли не превосходит 
уровней целостности ролей, которым она подчинена в иерархия ролей: для ролей г, г’ С Е ІІ 
ЫЕ ІІ АЕ, если г < г’, то іг(г) < іг(г’); 

• все административные роли из множества ЗАЕ обладают высоким уровнем целостности: 
для административной роли аг С ЗАЕ справедливо равенство іг(аг) = І_ііід1і. 

Условие 4 (уровни целостности и вид метки параметрически ассоциированных сущностей): 

• уровни целостность сущностей, параметрически ассоциированных с учетной записью 
пользователя , совпадает с её уровнем целостности , и метка таких сущностей всегда прямая: 
для е С ІІЕ верно сіігесі(е) = ігие, для сущностей е С]и[, где и С I/,справедливо равенство іе(е) 

= іи(и); 

• уровни целостности сущностей, параметрически ассоциированных с ролью или 
административной ролью, совпадают с её уровнем целостности, и метка таких сущностей 
всегда прямая: для е С ЕЕ верно сіігесі(е) = ігие, для сущностей е С ]г[, где г С К ІІ АЕ, 
справедливо равенство іе(е) = іг(г); 

• у запрещающих ролей множество параметричеки ассоциированных сущностей пусто: для 
запрещающей роли пг е N31 верно ]пг[ = О 

•сущности параметричеки ассоциированных с субъект-сессиями имеют прямую метку: для 
каждых сущностей е,е’ Е Е, учетной записи пользователя и Е ІІ, субъект-сессии 5^3 таких, 
что е е ір (и,е) или е е]з[, верно дігесі(е)=ігие 

Условие 5 (создание или удаление сущности, «жесткой» ссылки на неё, получение доступа 
к ней, изменение прав доступа ролей, запрещающих ролей или административных ролей к 
ней). 

• субъект-сессия может создать, удалить, переименовать сущность, «жёсткую* ссылку на неё 
или изменить права доступа ролей, запрещающих ролей или административных ролей к ней 
только, если эта сущность обладает уровнем целостности не выше текущего уровня 
целостности субъект-сессии; 

• любой доступ субъект-сессии к сущности, создание “жёсткой” ссылки на неё, получение или 
изменение параметров, прав доступа к ней, активизация из неё субъект-сессии должны осу¬ 
ществляться при выполнении условий доступа внутрь сущностей-контейнеров с учётом 
мандатных атрибутов целостности ССНі.цля субъект-сессии з Е 3 и сущности е Е Е,е ели 
(з,с,е) е А; то существует контейнер с е С и ехесиіе_сопіаіпег(з, с,е)=1гие, где а е На; 
•субъект-сессии может быть предоставлен доступ на запись к сущности только в случае, 
когда её уровень целостности не выше текущего уровня целостности субъект-сессии: для 
субъект-сессии з ^Зи сущности е еЕ, если (з, е, ѵѵгііе,) е А, то іе(е) « і(з); 

• задано множество сущностей-объектов Е_НОІ_Е с О, которое не изменяется на траекториях 
функционирования системы, доступы на запись или чтение к объектам из него не могут быть 



использованы для реализации информационных потоков по памяти (в них нельзя хранить 
данные). 

Условие 6 (создание или удаление роли, запрещающей роли административной роли, 
получение доступа к ней, изменение прав доступа административных ролей к ней, изменение 
иерархий ролей, администрирование функции необходимого обладания запрещающей 
ролью): 

• субъект-сессия может создать, удалить, переименовать, получит административный доступ 
к роли, запрещающей роли, административной роли, «жёсткой” ссылке на нее (изменить 
иерархию ролей, запрещающих или административных ролей) или изменить права доступа 
административных ролей к ней только , если эта роль , запрещающая роль или 
административная роль обладает уровнем целостности не выше текущего уровня 
целостности субъект-сессии : для субъект-сессии з е 3, роли, запрещающей роли или 
административной роли г е Н ІІ NN I) АН, если (з, г, аа) Е АА, то іг(г) < із(з), где аа Е На; 

•для изменения значения функции необходимого обладания запрещающей ролью сопзігаіпі 
N14 субъект-сессия должна иметь уровень целостности не ниже уровней целостности той 
роли или административный роли , для каждой меняется значение этой функции , а также 
запрещающей роли, которая добавляется или удаляется из множества значений этой 
функции; 

•если для некоторой роли или административной роли задана запрещающая роль , то уровни 
целостности этих ролей должны быть равны: для роли или административной роли г Е Я I) 
АН, если запрещающая роль пг Е сопзігаіпі NН(^), то іг® = іг(пг). 

Условия 7 (создание , удаление субъект-сессии, изменение её роли-«владельца»): 

• текущий уровень целостности активизируемой субъект-сессии не превосходит уровня 
целостности используемый для активизации сущности и уровня целостности учетной записи 
пользователя , от имени которой она функционирует , при этом должны быть учтены 
параметрически ассоциированные с ней сущности (должно быть выполнено предположение 
2.5); 

• субъект-сессия может изменить роль или административную роль, обладающую правом 
доступа владение к некоторой субъект сессии, или удалить субъект-сессию только с текущим 
уровнем целостности, не превосходящим текущего уровня целостности первой субъект- 
сессии; 

• субъект-сессия может назначить или удалить права доступа владение запрещающей роли 
к некоторой субъект-сессии только с текущим уровнем целостности , не превосходящим 
текущего уровня целостности первой субъект-сессии. 

Условие 8 (специальная сущность для доступа к элементам системы с высоким уровнем 
целостности). Задана специальная сущность-объект І_еп1і1у Е Е_НОІ-Е, обладающая высоким 



уровнем целостности іе(і_епШу) = і_ЫдЬ и прямой меткой сІігесі(і_епШу) = Ігие, получение 
доступа на запись к сущности І_еп1і1у субъект-сессией (или кооперирующей с ней другой 
субъект- сессией) является необходимым, когда она осуществляет следующие действия: 

• создаёт, удаляет, изменяет уровень целостности учетной записи пользователя 

• создает субъект-сессию с уровнем целостности выше і_Іоѵѵ т , 

• получает любой доступ к роли, запрещающей роли или административной роля с уровнем 
целостности выше і_Іоѵѵ т , 

• изменяет значение функции необходимого обладания запрещающей ролью сопзіаіпі пг для 
роли или административной роли с уровнем целостности выше /_/оі/и; 

• включает или исключает из числа запрещающих ролей для роли или административной 
роли запрещающую роль с уровнем целостности выше і_Іоѵѵ : 

• получает доступ на запись к сущности с уровнем целостности выше і_Іоѵѵ за исключением 
самой сущности І_еп1і1у, 

• создаёт, удаляет, переименовывает, изменяет параметры сущности, роли, 
административной роли или «жёсткой» ссылки на неё с уровнем целостности выше і_Іоѵѵ т , 

• изменяет содержимое сущности-контейнера, роли, запрещающей роли или 
административной роли с уровнем целостности повыше і_Іоѵѵ т , 

• изменяет права доступа ролей , запрещающих ролей или административных ролей к 
сущностям или субъект сессиям с уровнем целостности выше і_Іоѵѵ т , 

•изменяет административные права доступа административных 

ролей к ролям , запрещающим ролям или административным от ролям с уровнем 
целостности выше і_Іоѵѵ т , 

• изменяет уровень целостности сущности . 

Условие 9 (индивидуальные административные роли, индивидуальные роли учётной записи 
пользователя и общие роли ): 

•для каждой учётной записи пользователя и Е і! для к 
уровня целостности , не превосходящего её уровня цел задаются индивидуальные 
административные роли , не авторизована только эта учётная запись , множество 
авторизованных ролей учётной записи пользователя с использованием административных 
прав доступа административных ролей , определяемых функцией АРА, на траекториях 
функционирования системы у этих административных ролей не изменяются имена и уровни 
целостности, каждая такая индивидуальная административная роль обладает правами 
доступа на чтение, запись и выполнение ко всем индивидуальным административным ролям 
данной учетной записи пользователя с меньшим уровнем целостности ,при этом 
переопределено множество Ь[_АОМ/Л/.для каждых учетной записи пользователя и Е і! и 
уровня целостности //« іи(и) задается административная роль и_асІтіп_Іі е АП такая, что 



іг(и_с_Іі)=Іі, (ІІ_адтіп_Іі’,аг) е АРА(и_адтіп_Іі), где Іі’«Іі,аг 

Е{геаб, ѵѵгііе,ехесиіе}, ІІ_АОМІМ={и_асІтіп_Іі: и е ІІ,Іі«іи(и)}; 

• на множестве индивидуальных административных ролей учтённой записи пользователя 
задаётся иерархия, которая изменяется только при создании, удалении и изменении уровней 
целостности соответствующих учетных записей пользователей и является независимой от 
иерархии других административных ролей: для каждых учётной записи пользователя и Е ІІ \л 
её индивидуальных административных ролей и_адтіп_Іі, и_ас!тіп_Іі’, Е АН справедливо 
и_адтіп_Іі«и_асІтіп_Іі’ тогда и только тогда, когда //«//’; 

• определённая для каждой учётной записи пользователя и Е і! индивидуальная 
административная роль и_ас!тіп_і_Іоѵѵ.сч\лтается тождественной заданной в условии 9 
предположения 2.2 индивидуальной административной роли и_ас!тіп, при этом 
переопределено множество 1)_АОММ:верно и_ асітіп =и_ас!т іп_і_Іо\А/,ІІ_АОМІЫ={и_асітіп_Іі; 
и е ІІ,ІІ«іи(и)}; 

• для каждой учетной записи пользователя и Е ІІ для каждого уровня целостности, не 
превосходящего её уровня целостности, задаются индивидуальные роли, 
административными правами доступа на чтение, запись и выполнение к которым обладают 
ее индивидуальные административные роли с соответствующим уровнем целостности, на 
траекториях функционирования систем у этих административных ролей не изменяются 
имена и уровни целостности, при этом переопределено множество Ь[_ЯО/.Е5.для каждых 
учетной записи пользователя и Е ІІ и уровня целостности Іі«іи(и) задается роль и_с_Іі Е Н 
такая,что іг(и_с_Іі)=Іі,(и_с_Іі,аг) е АРА (и_асІтіп_Іо), где аг е {геад, ѵѵгііе,ехесиіе}, 
ІІ_НОІ-ЕЗ={и_с_Іі и е ІІ,ІІ«іи(и)}; 

•на множестве индивидуальных ролей учётной записи пользователя задается иерархия , 
которая изменяется только при создании, удалении и изменении уровней целостности 
соответствующих учетных записей пользователей и является независимой от иерархии 
других ролей: для каждых учетной записи пользователей изменения уровней целостности 
пользователя и Е ІІ и ее индивидуальных административных ролей и_с_Іі , и_с_Н' Е Н 
справедливо и_с_Іі«и_с_Іі’ тогда и только тогда , когда //«//’; 

•определённая для каждой учётной записи пользователя и Е ІІ индивидуальная роль и_с_ ( 
і _Іоѵѵ ) считается тождественной данной в условии 9 предположения 2 . 2 индивидуальной 
роли, при этом переопределено множество І!_Н0ІЕЗ\ верно и_с=и_с_(і_Іоѵѵ) , ІІ_НОІ-ЕЗ = { 
и_с_Іі; и е ІІ , Іі«іи(и). 

• для всех уровней целостности задаются общие роли , административными правами 
доступа на чтение , запись и выполнение к которым обладают индивидуальные 
административные роли всех учётных записей пользователей в соответствии с их уровнями 
целостности , при этом переопределено множество СОМ-МОЛ/_ НОІ-ЕЗ : для каждого уровня 



целостности Іі е и задана общая роль соттоп_Н, при этом іг ( соттоп_Іі) = //, и для каждой 
учётной записи пользователя и е ІІ верно ( соттоп_Іі,аг ) САРА ( и_ас!тіп_Іі ) ,где Іі « іи(и),аг, 
е { геасі , ѵѵгііег , ехесиіе}. СОММОМ_РОіЕ5 = {соттоп_Іі:Іі е и } ; 

• на множестве общих ролей задаётся иерархия , независимая от иерархии других ролей , 
которая не изменяется на траекториях функционирования системы : для общих ролей 
соттоп_Іі, соттоп_И еР. справедливо с соттоп_Іі« соттоп_Іі тогда и только тогда , когда 
Іі < Іі ’; 

• общая роль соттоп_(і_Іоѵѵ) считается тождественной заданной в условии 9 предположения 
2.2 общей роли соттоп_гоІе,при этом переопределено множество СОМ/ОѴ_ЯО/-Е$: верно 
соттоп_гоІе = соттоп( і_Іоѵѵ) ,СОММОМ_РОіЕ5 = { соттоп_Іі е /_/ } ; 

•для каждой индивидуальной административной роли, индивидуальной роли учётной записи 
пользователя, общей роли специальной административной роли множество сущность 
параметрически с ней ассоциированных, не изменяется в процессе 
функционирования системы ; 

•административные роли гоІез_асітіп_гоІе и асІтіп_гоІез_асІтіп_гоІе не используются для 
нарушения заданных иерарх вил назначения административных прав доступа к инициальным 
административным ролям , индивидуальные учетных записей пользователей и общим ролям. 
Условие 10 ( права доступа ролей , запрещающих ролей административных ролей ): 

•в начальном состоянии системы только учетные записи доверенных пользователей могут 
обладать административным ролями, имеющими права доступа к административным ролям, 
позволяющими получить права доступа владения к какой либо роли запрещающей роли или 
административной роли : в начальном состоянии системы для каждых учетной записи 
пользователя и Е і), роли или административной роли г Е Р ІІ Л/Я ІІ АЯ, административной 
роли 

и_ас!тіп_1і е АР ,где Іі Е и , если существует последовательность административных ролей 
агі... агп, где /V»7,таких,что аг1=и_асІтіп_Іі,(г,оѵѵп) е АРА(агп),(агі+1 , геасі) е АРА (аг), где 
і=1 ...,N-1 то ^/-учетная запись доверенного пользователя; 

• роль, запрещающие роль или административное роль может содержать право доступа на 
владение или запись к сущности с уровнем целостности не выше ,чем у роли запрещающие 
роли или административной роли: для роли или административной роли г Е Я ІІ Л/Я ІІ АР и 
сущность е е Е,е ели (е,аг) е РА(г), то іе(е)«іг(г), где аг е {оѵ/п,тііе}; 

•административная роль может содержать административное права доступа на владение, 
запись, или чтение к роли .запрещающие роли или административные роли с уровнем 
целостности не выше, чем у первой административной роли: для административной роли аг 
Е АР и роли, запрещающей роли или административной роли аг Е Аг и роли, запрещающей 



или административной роли г е Н ІІ Л/Я ІІ АН, если (г,а) е АРА (аг), то іг(г)«іг(аг),где аг е 
{оѵѵп,тіІе, геасі}; 

•роль, запрещающие роль или административное роль может содержать право доступа на 
владение к субъект-сессии с текущим уровнем целостности не выше, чем уровень 
целостности роли запрещающие роли или административной роли для: роли запрещающие 
роли или административной роли г е Н ІІ Л/Я ІІ АН и субъект-сессии з е 5, если (з,оѵѵп) е 
РА(г ),то із(з)«іг(г). 

Условие 11 (доступ субъект-сессии к индивидуальным административным, индивидуальным, 
общим ролям и их запрещающим ролям): 

• при создании каждой субъект-сессии она получает доступ на чтение к индивидуальным 
административным ролям, к индивидуальным ролям ее учетной записи пользователя и 
общим ролям, уровень целостности которых не превосходит текущего уровня целостности 
субъект-сессии з е 3 выполняются условия (з, изег(з)_адтіп_Іі, геад),(з, изег(з)_с_Іі, геад) е 
(з, соттоп_ІІ, геасі) е А А,где Іі«із(з); 

• при создании каждой субъект сессии она получает доступ на запись к единственным таким 
индивидуальной роли и общей роли, уровня целостности которых равны соответственно, 
текущему уровню целостности субъект сессии , и дуальная роль получает право доступа 
владения к созданной субъект-сессии: для субъект сессии з^З выполняются условия ( з,изег 
(з)_с_із,(з), і /ѵгііе) , (з ,соттоп_із,(з), тііе) е АА,(з,оѵѵп) е НА (изег(з)_с_із,( з)); 

• если для учётной записи пользователя индивидуальной административной роли или 
индивидуальной роли с некое уровнем целостности заданы запрещающие роли , то 
индивидуальная административная роль с соответствующим уровне , целостности этой 
учётной записи пользователя должна обладать административными правами доступа на 
чтение ко всем так , запрещающим ролям , и при создании от имени этой учётной за . писи 
пользователя субъект сессии она получает доступ на чтение ко всем соответствующим 
запрещающим ролям с соответствующим уровнем целостности : если для учётной записи 
пользователя и е I) выполняется пг е сопзігаіпі пг (и _ асітіп _ Іі ) ІІ сопзігаіпі Л/Я (и _ с_ 
Іі), то (пг, геасі) е АРА (и_асІтіп_Іі) 

• если для общей роли с некоторым уровнем целостности заданы запрещающие роли , то 
индивидуальная административная у роль каждой учётной записи пользователя , 
соответствующая 

этому уровню целостности , должна обладать административными правами доступа на 
чтение ко всем таким запрещающие ролям , и при создании субъект сессии она получает 
доступ на чтение ко всем соответствующим запрещающим ролям с соответствующим 
уровнем целостности : если выполняется пг Е сопзігаіпі пг ( соттоп_Іі ) , то для всех учётных 
записей пользователей и Е ІІ верно ( пг , геасі ) Е АРА ( и _ асітіп _ Іі ) , и для субъекта- 



сессии 8 е 5 верно ( з , пг , геасі ) е АА , где //« із ( х ) ; 

• при удалении субъект сессии удаляются все её доступ индивидуальным административным 

, индивидуальным и общим ролям 

- Условие 12 ( администрирование уровней целости, параметров , имён сущностей , ролей 
и административных ролей): 

• изменение уровня целостности , мандатного атрибута целостностиССПІ роли, 

запрещающей роли или административной роли ( со значения ІаІзе ) запрещено ; 

• сущности-контейнера создаются с мандатным атрибутом целостности ССВІ равным ігие; 
•для изменения мандатного атрибута целостности ССВІ сущности-контейнера субъект 
сессии необходимо обладать либо теку ей ролью или административной ролью , имеющей 
право доступа владения к этой сущности контейнеру , либо доступом на чтение к 
административной роли еп1Шез_ адтіп гоіе ; 

•для изменения субъект сессией уровня целостности сущности к 
ей не должно быть доступов , и требуется наличие у субъект сессии текущей 
административной роли епІіііез_ адтіп гоіе. 

Условие 13 ( администрирование учётных записей пользователей ) : 

• для изменения уровня целостности учётной записи пользователя требуется наличие у 
субъект сессии текущих административных ролей изег_ адтіп _ гоіе , гоіез _ адтіп _ гоіе , 
педаІіѵе_гоІез_ адтіп гоіе и асІтіп_гоІез_асІтіп_гоІе из множества ЗАВ , при этом множество 
субъект-сессий, функционирующих от имени данной учётной записи пользователя , должно 
быть пустым ; 

• субъект-сессия может создать, удалить или изменить уровень 
целостности учётной записи пользователя с уровнем целостности не выше текущего уровня 
целостности этой субъект-сессии. 

Рассмотрим особенности реализации в ОССН условий предположения 2.9. 
Условия 1 3 определяют порядок задания уровней целостности сущностей , ролей , 
запрещающих ролей и административных ролей ( по аналогии с сущностями ) с учётом их 
иерархии , уровней целостности учётных записей пользователей и субъект сессий с учётом 
их иерархии . Кроме того , в условии 1 определяется порядок задания уровней целостности 
учётных записей доверенных и недоверенных пользователей , что также обеспечивает 
чёткую классификацию компонентов ОССН на критичные и некритичные для обеспечения ее 
без опасности.. При этом недоверенными считаются все учётные записи пользователей , 
уровень целостности которых меньше і_ІіідІі .Уровни целостности сущностей с косвенной 
меткой задаются аналогично правам доступа к ним. 

Так как в рамках уровня мандатного контроля целостности 
МРОСЛ ДП- модели рассматриваются сущности , параметрически ассоциированные с 



учётными записями пользователей, ролями запрещающим ролями или административными 
ролями , (которых позволяет либо создать субъект сессию о соответствующей учётной записи 
пользователя , либо полу ответствующей роли ) , то по условию 4 их уровень жен совпадать 
с уровнем целостности учётной записи или уровнем целостности роли ( административной 
роли) соответсвенно ( при этом у запрещающих ролей не должно бы параметрически с ними 
ассоциированных , что связано необходимостью обеспечения возможности получения 
запрещающих ролей как текущих всеми субъект сессиями , когда для их ролей 
административных ролей указаны запрещающие роли , а также запрещающие роли не 
расширяют права доступа субъекта наоборот , сокращают их ) . В ОССН маловероятна 
ситуация таких сущностей будет косвенная метка , в связи с этим треба чтобы она всегда 
была прямая . Описание таких сущностей в ОССН может быть легко реализовано . В то же 
время аналогичное описание сущностей , параметрически или функционально 
ассоциированных с субъект сессиями , труднореализуемо на практике . Выявление таких 
сущностей является самостоятельной задачей при разработеке защищённой ОССН . В связи 
с этим постулирование в предположениях модели аналогичных требований для сущностей , 
параметрически или функционально ассоциированных с субъект сессиями 
нецелесообразно . Вместе с тем соответствует условиям функционирования ОССН 
предположение о том , что только сущность с прямой меткой может являться параметрически 
ассоциированной с субъект сессией. 

Условия 5,6 и 7 задают для субъект сессий порядок создания , удаления , переименования 
, получения доступа к суши субъект сессиям , ролям , запрещающим ролям или 
административным ролям , администрирования функции необходимого запрещающей ролью 
сопзігаіпШК с учётом мандатного к целостности . Так как для него не представляют угроза 
информационные потоки по времени , то требования предъявляются доступам к сущностям 
на запись Для обеспечения условий реализации в ОССН некоторых типовых ресурсов во 
множество включены специальные объекты дырки » , которые не использованы для создания 
информационных потоков по памяти ( например , “слушающие “ сокеты ) . При доступе к 
ролям, запрещающим ролям или административным ролям требует доступ на чтение , так 
как он соответствует авторизации на текущую роль субъект сессией , и , следовательно , ее 
уровень целостности должен быть не ниже чем уровень целостности роли. При этом должно 
быть предусмотрено два способа создания субъект-сессий. Первый, когда субъект-сессия 
создается с “разрывом” связи с создающей субъект-сессией как первая субъект-сессия- 
корень иерархии (например , по командам зидо или зитас). В этом случае возможно создание 
субъект-сессии с уровнем целостности не выше уровня целостности учетной записи 
пользователей, от имени которой она создается. Второй способ, когда субъект-сессия 
создается как потомка активизирующей субъект-сессии. В этом случае ее уровень 



целостности должен совпадать с уровнем целостности создающей субъект-сессии. Порядок 
создания сущностей или “жестких” ссылок на них в зависимости от вида их меток следует из 
условия 2. 

Условие 8 задаёт в рамках модели требования к реализации механизма защиты, 
аналогичного механизму ІІАС в ОС семейство МісгозоП ѴѴІпсІоѵѵз. Данный механизм 
предполагает что для осуществления ряда действий с использованием высокого уровня 
целостности требуется реализация доступа на запись к специальной сущности. В ОС 
семейства МісгозоП ѴѴІпсІоѵѵз такому доступу соответствует возможность подтвердить 
(нажать кнопку на защищённой системном рабочем столе, доступ к которому запрещён для 
пользовательского ПО) необходимость выполнения действий с высоким уровнем 
целостности. Это условие требует, чтобы доступ запись субъект-сессией (или 
кооперирующей с ней другой субъект-сессией)к специальной сущности-объекту і_епМу 
реализовывался всегда осуществляются изменения уровней целостности или иные любые 
действия с учётными записями пользователей, ролями, запрещающими ролями, 
административными ролями, сущностями, субъект-сессиями с уровнями целостности выше 
минимального-/_/оил 

Применение по условию 9 соответствующих уровням целостности индивидуальных 
административных и индивидуальных ролей учетных записей пользователей и общих ролей 
для задания их авторизованных ролей <прав доступа к сущностям направлен на 
обеспечение приоритетности и монолитности мандатного контроля целостности и в первую 
очередь в дальнейшем мандатного управления доступом как при исправлении доступом к 
сущностям так и при использовании или администрировании ролей. 

Выполнение условия 10 позволяет предотвратить несанкционированное администрирование 
и изменение иерархии ролей недоверенными субъект-сессиями. Такие субъект-сессии 
изначально ( в начальном состоянии системы) лишаются возможности получить (через 
соответствующую административную роль) право доступа владения к любой роли. При этом 
одной из задач по обеспечению безопасности системы является предотвращение 
возможности перехода систем в состоянии в котором не будет выполняться часть условия 
9,заданная для начального состояния системы. В соответствии с условием 9 для каждой 
роли, запрещающей роли или административной роли разрешается иметь права доступа на 
владение и запись только сущностям, ролям, запрещающим ролям или административным 
ролями с уровнем целостности не выше уровня целостности первой роли. Для соответствия 
условию 5,которое разрешает получение субъект-сессии доступа на чтение к роли. Таким 
образом, в соответствии с условиями 5-9 в модели задаются три «рубежа защиты» 
мандатного контроля целостности: первый — контроль уровней целостности при 
непосредственно предоставлении субъект-сессиям доступов к сущностям, ролям, 



запрещающим ролям или административным ролям; второй — необходимость субъект- 
сессии при осуществлении действий на высоком уровне целостности получать доступ на 
запись к специальной, особо защищаемой ОССН сущности; третий — назначение каждой 
роли, запрещающей роли и административной роли прав доступа на владение и запись (и в 
ряде случаев на чтение) в соответствии с её уровнем целостности. 

Условие 11 задаёт порядок получения доступа на чтение (авторизации) на индивидуальные 
административные роли учётной записи пользователя функционирующей от её имени 
создаваемой субъект-сессией; также доступов на чтение и запись на индивидуальные роли 
этой учётной записи пользователя и общие роли в зависимости от уровня целостности 
субъект-сессии. Кроме того, определяется порядок получения субъект-сессией как текущих 
запрещающих ролей, если они заданы с помощью функции сопзіаіпг пг для текущих 
индивидуальных ролей его учетной записи пользователя и общих ролей. При этом требуется 
предоставление его индивидуальным административным ролям необходимых 
административных прав доступа на чтение к запрещающим ролям с учетом их уровней 
целостности. 

Условие 12 предназначено для защиты от несанкционированно изменения мандатных 
атрибутов целостности ССПІ, уровней целостности ,имен ролей запрещающих ролей 
административных ролей и сущностей. При этом изменение уровней целостности ролей, 
запрещающих ролей или административных ролей запрещено ,так как выполнение условия 
9 при изменении такого уровня целостности всех сущностей к которым данная роль имеет 
права доступа на владение или запись, что в ОССН практически нереализуемо. Порядок 
изменения условия 2 и условия 8 предположения 2.2. 

Условие 13 задает порядок администрирования (создания, удаления) учетных записей 
пользователей, получения их параметров с учетом мандатного контроля целостности, для 
получения их параметров с учетом мандатного контроля целостности, для чего требуется 
специальные административные роли изег_адтіп_гоІе,гоІез_асітіп 

гоІе,педаііѵе_гоІез_асІтіп_гоІе и ас/тіп_гоІез_асІтіп_гоІе. 

2.3.4. Фактическое владение и де-факто правила 
преобразования состояний 

Ранее при разработке ДП-моделей для отражения ситуации, когда одна субъект-сессия 
получает контроль над другой субъект-сессией использовался доступ владения оѵѵпа.В то же 
время в ОССН такой доступ, как правило явно не задаётся. Например, когда субъект-сессия 
осуществляет откладку другой субъект-сессии или когда первая субъект-сессия через 
переполнение буфера памяти получила над ней контроль. В связи с этим используем 
обозначение, дадим определение и сделаем предположения: 

Ое_1асІо_оѵѵп:5-2з- функция де-факто владения субъект-сессиями. 



Определение 2.6. Будем говорить, что субъект-сессия 5 де-факто владеет субъект-сессией 
5 когда выполняется условие з’ е де_іасІо_оѵѵп(з). При этом по определению всегда з е 
сІе_ІасІо)оѵѵп(з). 

Предположение 2.10. Если субъект-сессия з реализовала информационный поток памяти 
от себя к сущности, функционально ассоциированной с другой субъект-сессией з’ или 
субъект-сессия реализовала информационный поток по памяти от себя кз’ик себе от всех 
сущностей параметрически ассоциированных с другой субъект-сессией з’ то субъект-сессия 
з получает де-факто владение субъект-сессией з’ (з’ е сІе_іасІо)оѵѵп(з)). 

Предположение 2.11. Если субъект сессия з де-факто владеет субъект сессией з ' , то с 
учётом наличия у субъект-сессии з’ текущих запрещающих ролей субъект сессия з получает 
возможности : 

• использовать доступы субъект сессии з ' к сущностях .административным ролям ; 

• инициировать от имени субъект сессии з ' выполнение правил преобразования состояний 
системы ; 

• получать де факта владение субъект сессиями , которые де-факто владеет субъект сессия 
з'; 

• использовать информационные потоки , в реализации которых участвует субъект сессия 
з'; 

• удалить субъект сессию з’. 

Используем обозначения 

сіе_ІасІо_ассеззез: — функция де факта доступов субъект сессий , при этом по определению 
в каждом состоянии системы О для каждой субъект сессии 3^5 верно равенство. 
Определение 2.7. Доступы из множества с/е іасіо _ ассеззез ( з ) будем называть де факта 
( фактическими ) доступами субъект сессии з. 

Фактическое владение , фактические доступы не требуют реализации в ОССН и 
используются для теоретического анализа её без опасности , а также для упрощения записи 
де факта правил преобразования состояний системы . При этом де факта владение субъект 
сессией другой субъект сессией позволяет первой из них управлять второй и пользоваться 
её возможностями ( в том числе от ее имени правами доступа её текущих ролей или 
административных ролей). Однако , если у второй субъект сессии имеются запрещающие 
роли , обладающие некоторыми правами доступа , то воспользоваться соответствующими 
правами доступа для получения доступа к сущностям или субъект сессиям от имени второй 
субъект сессии можно 

С учётом добавления в модель по сравнению с её уровнем ролевого управления доступом 
мандатного контроля целостности рожденной решеткой уровней целостности де юре правила 
преобразования состоянии дополняются соответствующими условия результатами их 



применения . Всего на уровне мандатного контроля целостности МРОСЛ ДП-модели заданы 
38 де-юре правила преобразования состояний, из которых три правила вида 
зеІ_изег_ІаЬеІз,зеІ_епііІу_ІаЬеІз и зеІ_гоІе_ІаЬеІз отсутствовали на уровне ролевого 
управления доступом так предназначены для изменения уровней целостного учётных 
записей пользователи или сущности а также сущностей параметрически ассоциированных с 
учетными записями пользователей или ролями. При этой для каждого правила в табл. 2.2. в 
первой строке укажем его параметры условия и результаты применения наследованные с 
уровня ролевого управления доступом без изменения соответствующие уровню мандатного 
контроля целостности МРОСЛ ДП-модели. 

Так как получение доступа на чтение с использованием де-юре правила вида 
ассез5_геасІ(х,х’у) к роли, запрещающей роли или 


Примеры де-юре правила преобразования состояний МРОСЛ ДП-модели уровня мандатного 
контроля целостности 

Таблица 2.2 



















административной роли означает получение её как тек этом случае требуется , чтобы 
уровень целостности роли у не превосходил текущего уровня целостности субъект - сессии 
х обладала доступами на чтение или на запись ко всем сущностям параметрически 
ассоциированным су, а когда уровень целости у выше минимального і_Іоѵѵ, то субъект сессия 
х 'имела доступ на запись к сущности і_епіііу . 

Де юре правило вида зеІ_епЫу _ ІаЬеІз ( х, х, у, у/) до субъект сессии х задать сущности у с 
прямой меткой ( не являющиейся параметрически ассоциированной ни с одной ролью или 
записью пользователей , и к которой на момент применения по ни одна субъект сессия 
системы не имеет доступов ) её новый урок целостности , для чего требуется наличие у х 
административного ступа на чтение к административной роли еп1Шез_ ас!тіп_ гоіе . При этом 
текущие и устанавливаемые уровни целостности сущности и не должны превосходить 
текущего уровня целостности субъект сессии х . Кроме того , устанавливаемый уровень 
целостности сущности у не должен превосходить уровней целостности всех сущностей 
контейнеров , в которых непосредственно находится у , и , наоборот , должен быть не ниже 
уровней целостности всех сущностей , непосредственно входящих в у , а также не должен 
превосходить уровней целостности всех ролей , запрещающих ролей или административных 
ролей , обладающих к ней правами доступа на владение или на запись . Когда у всех 
сущностей , подчинённых сущности у , метки косвенные , и к ним не имеют доступов субъект 
сессии , то их уровни целостности устанавливаются равными новому значению уровня 
целостности сущности у . Если либо текущий , либо устанавливаемый уровень целостности 
сущности у является уровнем целостности больше минимального і_Іоѵѵ , то требуется 
наличие у кооперирующей субъект сессии доступа на запись к сущности і_епіііу . 

Де факто правила преобразования состояний ( табл .2.3) вводятся на уровне мандатного 
контроля целостности МРОСЛ ДП модели так как на её уровне ролевого управления 
доступом не рассматриваются информационные потоки и фактическое владение . 

На текущем уровне модели заданы 9 де факто правил преобразования состоянии , условия 
и результаты применения которая ответствуют предположениям модели . Эти правила не 
требуют реализации в ОССН ( их применение не приводит к изменения параметров ) , а 
предназначены для теоретического анализа ее безопасности в рамках МРОСЛ ДП модели . 
Некоторые де факто е могут инициироваться только недоверенными субъект-сессиями, 
которыми являются все субъект-сессии с уровнем целостности меньшим максимального 
і_НідМ. 



Де-факто правила преобразования состояний увроня мандатного контроля целостности 
МРОСЛ ДП-модели 



Таблица 2.3 


Де факто правило вида де_!ас1о ор (8 , ор(х,х ’...))позволяет недоверенной субъект сессии 8 
, де факто владеющей субъект-сессиями хих’, выполнить от имени х где де- юре правило. 
Данное правило позволяет исключить из рассмотрения де факто возможности субъект- 
сессии а также описать условия и результаты применения де юре правил преобразования 
состояний в виде , адаптированном реализации в ОССН . Перечисленные в условии при де 
юре правила , которым не может являться орт обладания субъект сессией с текущими 
административные с высоким уровнем целостности ( т . е . высокого те целостности субъект 


















сессии х ) , что означает преодоление : ной субъект сессией в защиты системы и 
бессмысленность дальнейшего анализа её безопасности. 

Де факто правила видов сопігоі ( х , у, і ) и кпоѵѵ (х , у) позволяют недоверенной субъект 
сессии х получить де факто владение субъект сессией у . При использовании первого 
правила требуется . чтобы нашлась сущность 2 , функционально ассоциированная с субъект 
сессией у , и существовал информационный поток по памяти у . При использовании второго 
правила требуется существование информационных потоков по памяти от х к г т от всех 
сущностей ( как минимум , одной ) , параметрически ассоциированных с субъект сессией у . 
Кроме того , в отличие от предшествующих ДП моделей добавлено условие наличия 
информационного потока по памяти от что соответствует наличию « канала управления » 
субъект попадающей под контроль ( де факто владение ) субъект ( в случае с правилом вида 
сопігоі (х , у, т.) описание так тельного канала не требуется , так как « управление » может 
осуществляться через сущность т. , функционально ассоциированную с у). 

Де-факто правило вида Іаке_ассезз_оѵѵп(х,у, 2 ) позволяет недоверенной субъект-сессии х 
получить де-факто владения субъект-сессией х.При этой требуется чтобы субъект-сессия х 
де-факто владела субъект-сессией хлибо обладающей соответствующими ролями текущими 
уровнем целостности позволяющим ей использовать право доступа владения к субъект- 
сессии ху одной из своих текущих ролей, а также отсутствие у субъектов-сессии у текущей 
запрещающей роли, обладающей этим правом доступа к х. 

Де-факто правило вида ІІоѵѵ_тетогу_ассезз(х,у,а) позволяет субъект-сессии х имеющей де- 
факто доступ на чтение или на запись к сущности у, не входящей во множество 
Е_НОІ-Е, реализовать информационный поток по памяти от у кх или от х к у соответственно. 
Де-факто правило вида Іаке_(Іоѵѵ(х,у) позволяет недоверенной субъект-сессии х,фактически 
владеющей субъект-сессией у,реализовать информационные потоки по памяти ко всем 
сущностям или субъект-сессиям, к которым имеет информационные потоки по памяти 
субъект-сессия у. 

Де-факто правила вида ІіпсІ(х,у,і),розі(х,у,х) и разз (х,у,г) позволяют субъект-сессиям 
создавать информационные потоки по памяти, в основном аналогично соответствующим 
правилам, использованным в предыдущих ДП-моделях, а также в расширенной модели Таке- 
ОгапІ[17,1 16\. Отличия в условиях и результатах применения этих правил заключаются 
невозможности применения для создания информационных потоков по памяти сущностей из 
множества Е_НОІ-Е. 

На уровне мандатного контроля целостности МРОСА ДП-модели можно доказать 
утверждение, аналогичное утверждению 2.1, о корректности задания де-юре и де-факто 
правил преобразования состоянии, т. е. о их соответствии условиям предположений 2.2 и 2.9. 



2.3.5. Нарушение безопасности системы в смысле 
мандатного контроля целостности 

При анализе условий нарушения безопасности системы на уровне мандатного контроля 
целостности МРОСА ДП-модели по аналогии с предшествующими ДП-моделями 
предполагается, что на траекториях функционирования системы доверенные субъект-сессии 
не кооперируют с недоверенными при администрировании учётных записей пользователей, 
сущностей, субъект-сессий, ролей, запрещающих ролей или административных ролей, 
получении доступов или административных доступов, изменении параметров, создании или 
Удалении сущностей, ролей, запрещающих ролей, административных ролей или «жёстких» 
ссылок на них, запрещающих ролей для Ролей или административных ролей, создании или 
удалении субъект-сессий. Кроме того, в ОССН создаются сущности (например, сокеты), через 
которые осуществляется безопасный обмен данными между доверенными и недоверенные 
субъект-сессиями, т. е интерфейсы взаимодействия через такие сущности тщательно прове¬ 
ряются (верифицируется и минимизируется код ПО, реализующего такие интерфейсы 
.реализуются процедуры фильтрации передаваемых данных),и обосновывается 
невозможность их использования для получения недоверенным субъект-сессиям. В связи с 
этим дадим следующие определения. 

Определение 2.8. Субъект-сессию у, обладающую уровне целостности выше минимального 
( і_Іоѵѵ<із(у )), назовем функционально корректной относительно субъект-сессии у , 
обладающей уровнем целостности не выше уровня целостности первой субъект- сессии 
(із(у)«із(у)). и сущности или субъект-сессии е, когда субъект-сессия у не реализует 
информационный поток по памяти от сущности или субъект-сессии е к некоторой сущности с 
, функционально ассоциированной с субъект-сессией у'. Субъект-сессию у назовём 
абсолютно функционально корректной относительно субъект-сессии у' и сущности или 
субъект-сессии е, когда субъект-сессия у не реализует информационный поток по памяти от 
сущности или субъект- сессии е к некоторой сущности е\ функционально ассоциированной с 
субъект-сессией у'. При этом используем обозначения: 

і_соггесІ{ з Е 5 I і_Іоѵѵ<із(з ))- функция, задающая для каждой субъект-сессии, обладающей 

уровнем целостности выше минимального, множество пар вида субъект-сессия и сущность 

или субъект-сессия, относительно которых она функционально корректна; 

аі_соггесі 8- функция, задающая для каждой субъект-сессии множество пар вида субъект- 

сессия и сущность или субъект-сессия, относительно которых она абсолютно функционально 

корректна. 

Определение 2.9. Субъект-сессию у,обладающую уровнем целостности выше минимального 
( і_Іоѵѵ<із(у )), назовём параметрически корректной относительно субъект-сессии у', 
обладающей уровнем целостности не выше уровня целостности первой субъект- сессии 



(із(у’)«із(у)) ,и сущности или субъект-сессии е, когда субъект-сессия у не реализует 
информационный поток по памяти к сущности или субъект-сессии е от некоторой сущности 
е', параметрически ассоциированной с субъект-сессией у’. Субъект-сессию у назовем 
абсолютно параметрически корректной относительно субъект-сессии у и сущности или 
субъект-сессии е, когда субъект-сессия у не реализует информационный поток по памяти к 
сущности ил» субъект-сессии е от некоторой сущности е', параметрически ассоциированной 
с субъект-сессией у\ При этом используем обозначения: 

р_соггесІ { з е 3 /і_Іоѵѵ<із(з)}-фуищ\ля, задающая для каждой доверенной субъект-сессии 
множество пар вида доверенная субъект-сессия и сущность или субъект-сессия, 
относительно которых она праматрически корректна. 

Ар_соггесІ:8-фунщ\ля, задающая для каждой субъект-сессии множество пар вида субъект- 
сессия и сущность или субъект-сессия, относительно косоротых она абсолютно 
параметрически корректна. 

Определение 2.10 . Назовём траекторию Оо 01...Оп системы I ( О’, ОР, Оо ) , где N>>0 , 
на которой довременные субъект сессии не инициируют выполнение де юре правил 
преобразования состояний , траекторией без кооперации доверенных и недоверенных 
субъект сессий . Таким образом , по определению в системе ( С " , ОР , СО ) на траекториях 
без кооперации доверенных и недоверенных субъект сессий для передачи прав доступа 
доверенные субъект сессии могут инициировать выполнение только де факта правил (Іоѵѵ _ 
тетогу_ ассезз (х, у, а ), /шс/(х, у, і ), розі (х, у, я) и разз (х, у , і) . 

По определению 2 . 10 на траекториях без кооперации доверенных и недоверенных субъект 
сессий могут инициировать выполнение любых де юре или де факта правил все 
недоверенные субъект сессии из множества N5 ( имеющие уровень целостности меньше 
максимального і_ЬідІі ) . 

На уровне мандатного контроля целостности МРОСЛ ДП модели целесообразно определить 
соответствующий смысл нарушения безопасности системы и дать определение безопасного 
состояния системы , так как в дальнейшем с учётом включения в последующие уровни 
модели мандатного управления доступом будут добавлены другие смыслы нарушения 
безопасности системы . При этом , поскольку после нарушения безопасности системы в 
одном из состоянии некоторой траектории дальнейший её анализ не имеет смысла , 
целесообразно рассматривать траектории , нарушение безопасности системы на которых 
возможно только в их конечном состоял также учесть , что захват контроля субъект сессией 
с меньшим уровнем целостности над субъект сессией не обязательно доверенной имеющей 
больший уровень целостности , следует рассматривать нарушение безопасности в смысле 
мандатного контроля целостности . Дадим определения. 



Определение 2.11. Начальное состояние Со системы I (С’, ОР , Со ) назовём безопасным 
, когда оно удовлетворяет следую условиям . 

Условие 1. Для каждых субъект-сессий х,у Е 30 таких, что у Е 0е_іас1о_оѵѵп(х), верно 
ізо(у)«ізо(х). 

Условие 2.Для каждых недоваренной субъект-сессии х Е N30, субъект-сессии у Е Зо и 
сущности е е Е таких, что либо (е е [у] и (х,е,ѵѵгіІе) е Ео), либо (е е ]у[ и либо (е,х,ѵѵгИе) е 
Ео,либо (х,е,геасІ) е Ео,), либо (х,е,геасІ) е АО), верно неравенство ізо(у)«ізо(х). 

Условие 3. Для каждой доверенной субъект-сессии у Е і-зо верно условие (у,і_епІІІу,ѵѵгіІе) Е 
Ао. 

Условие 4. Для каждого информационного потока (х,у,ѵѵгі1е) Е Ео справедливо 
іхо(х)»іуо(у), где іхо и іуо- соответствующие функции ісо или ізо. 

Определение 2.12. Пусть Ѳо-безопасное начальное состояние системы Е (О’, ОР , Со ) и 
существует траектория без кооперации доверенных и недоверенных субъект-сессией Оо 
31 ...Зп, где N>>1.Будем говорить что в состоянии (Зп произошло нарушение безопасности 
системы в смысле мандатного контроля целостности когда существуют недоверенная 
субъект-сессия хе N30 и субъект-сессия у Е 0е_1ас1о_омпх(х) такие что не верно неравенство 
із(у)«із(х). 

Проанализируем условия определений 2.11 и 2.12. Выполнение заданных в определении 
2.11 требований к начальному состоянию (кроме условий предположений 2.2 и 2.9) 
обеспечивает отсутствие в нем недоверенных субъект-сессий либо фактически владеющих 
субъект-сессиями, обладающими более высоким текущим уровнем целостности, либо 
имеющих возможность получения контроля над такими субъект-сессиями с использованием 
сущностей, параметрически или функционально с ними ассоциированными. Также в 
начальном состоянии предполагается отсутствие запрещённых информационных потоков по 
памяти от сущностей или субъект-сессией с низким уровнем целостности к сущностям или 
субъект-сессиям с более высоким или несравнимым уровнем целостности. В результате в 
начальном состоянии не выполняется условие определения 2.12-не происходит нарушение 
безопасности системы в смысле мандатного контроля целостности. Кроме того в этом 
состоянии отсутствуют доверенные субъект-сессии имеющие доступ на запись к специальной 
сущности і_епМу, заданной в условии 8 предположения 2.9,что не позволяет недовереным 
субъект-сессиям сразу реализовывать попытку повышения своего уровня целостности. 
Однако допускается что в начальном состоянии доверенные субъект-сессии де-фекто 
владеют другими субъект-сессиями. 

Как правило, в ОССН захват контроля (получение фактического владения) над процессами 
(субъект-сессиями) других учетных записей пользователей не является для нарушителя 
самоцелью. При реализации в ней мандатного управления доступом целью субъект-сессия 



нарушителя, вероятно, будет создание соответствующих запрещённых информационных 
потоков «сверху вниз». Для чего эта субъект-сессия будет либо сразу пытаться реализовать 
данные запрещённые информационные потоки, либо сначала, «взломав» защиту' ОССН, 
получить фактическое владение субъект-сессией с более высоким уровнем целостности или 
даже доверенной субъект-сессией (осуществить нарушение безопасности в смысле 
мандатного контроля целостности и, как правило, полный захват контроля над системой) и 
реализовать запрещённые информационные потоки с её использованием. При этом 
доверенные субъект-сессии не будут кооперировать с недоверенными, т. е. не будут 
реализовывать де- юре правила и ограничатся использованием только перечисленных в 
определении 2.10 четырёх де-факто правил с учётом корректности субъект-сессий в смыслах 
определений 2.8 и 2.9. 

Достаточные условия безопасности системы в смысле мандатного контроля целостности (в 
соответствии с определением 2.12) при безопасном её начальном состоянии 
обосновываются в следующей теореме. 

Теорема 2.1.Пусть Ѳо- безопасное начальное состояние системы I (О’, ОР , Оо ). Пусть на 
всех траекториях системы без кооперации доверенных или недоверенных субъект-сессий 
00,01 ,Оп,где N>>0 ,и в каждом состоянии Оп для каждой субъект-сессии з ^5 и сущности е 
Е Е выполняются следующие условия. 

Тогда на этих траекториях система I (0\ ОР , Оо ^безопасна смысле мандатного контроля 
целостности (в смысле определения 2.12). 

Условия теоремы требуют от ОССН функционально и параметрически корректной 
реализации субъект-сессий и задания соответствующих уровней целостности 
функционально или параметрически ассоциированных с ними сущностей. В ней 
сформулированы дополнительные требования к де-юре правилам преобразования 
состояний системы, создающим субъект-сессии (при этом задаются сущности, 
параметрически или функционально с ними ассоциированные), создающим сущности, 
изменяющим права доступа к ним или их параметры, так как эти сущности могут оказаться 
функционально или параметрически ассоциированными с субъект-сессиями. 

Говоря о разработке уровня мандатного контроля целостности иерархического 
представления МРОСЛ ДП-модели для СУБД РозІдгеООЦсм. рис. 2.1), целесообразно 
отметить следующее. Во- первых, потребовалось учесть существенные особенности 
реализации этого механизма управления доступом в СУБД. Например, чтобы не снижать 
производительность СУБД было предложено назначать уровни целостности элементам 
СУБД до схем включительно, т. е. не назначать их таблицам, функциям, триггерам. Во- 
вторых, определить значимые для реализации мандатного контроля целостности требования 
к использованию функций как элементов СУБД, включив в модель режимы их выполнения, 



задаваемые в СУБД параметрами 8ЕСІІНІТУ ОЕЕІМЕЯ и 5ЕСІІВІТѴ ІІМѴОКЕВ (в модели с 
помощью функции дЬ_зесигіІу), Так как, очевидно, функция СУБД влияет на 
функциональность активизировавшей её субъект- сессии, то содержащая функцию 
сущность-схема СУБД была определена функционально ассоциированной с такой субъект- 
сессией, а уровень целостности этой сущности-схемы задан не ниже текущего уровня 
целостности субъект-сессии. При этом для режима выполнения функции СУБД с правами 
роли СУБД являющейся ее владельцем уровень целостности этой роли СУБД определён 
строго равным уровню целостности сущности-схемы содержащей функцию. 

2.4 Уровни мандатного управления доступом 
2.4.1 Элементы состоянии системы 

Мандатное управление доступом с контролем информационных потоков по памяти и по 
времени требует достаточно большего описание соответствующих им уровней МРОСЛ ДП- 
модели что выходит за рамки настоящего учебного пособия. Поэтому рассмотрим только 
наиболее существенные из них элементы. Используем обозначения: 

(І_С,«)- решетка многоуровневой безопасности уровней конфиденциальности (декартово 
произведение линейной шкалы уровней конфиденциальности данных и множества всех 
подмножеств конечного множества иерархических категорий данных).При этом заданы 
максимальный с_1іід1і=+іс и минимальный с_Іом\/=+іС элементы решетки соответственно. 
(іи,іе,іг,із) е ЕС- четверка функций уровней конфиденциальности при этом: 

Рг/;/>/-С-функция задающая для каждой учетной записи пользователя ее уровень доступа- 
максимальный разрешенный уровень субъект-сессии функционирующий от ее имени; 
/ г 5.'5-/-С-функция задающая для каждой субъект-сессии ее текущий уровень доступа; 

Яе;Е-/_ С-функция задающая роль конфиденциальности для каждой сущности; 

ЕС-множество всех четверок функций заданного вида; 

ССЯ:Е ІІ Я ІІ Л/Я ІІ АЯ-{Ігие,ІаІзе}-фунщ\ля задающая способ доступа к сущностям внутри 
контейнеров или ролям в иерархии ролей .Если сущность е Е С является контейнером 
е,разрешен без учета уровня конфиденциальности контейнера е,то по определению 
выполняется равенство ССЯ(е)=іаІзе, в противном случае выполняется равенство 
ССЯ(е)=ігие. При этом по определению для каждой сущности объекта о Е О выполняется 
равенство ССЯ(о)=1гие, для ролей, запрещающих ролей или административных ролей г Е ЕІ ІІ 
Л/Я ІІ АЕІ всегда выполняется равенство ССЯ(г)=іаІзе. 

Также во множество специальных административных ролей ЗАВ добавлена обладаемая 
высоким уровнем целостности роль с!оѵѵпдгасІе_ас]тіп_гоІе, позволяющая доверенным 
субъект-сессиям нарушать требования мандатного управления доступом. 

Мандатные атрибуты конфиденциальности сущностей-контейнеров СОВ целесообразно 
реализовать в ОССН с целью обеспечения большей гибкости мандатного управления 



доступом. Мандатные атрибуты конфиденциальности ССВ для ролей использовав для 
единообразия с сущностями, так как при реализации ролевого управления доступом 
предполагается, что наличие возможное получения субъект-сессией некоторой роли всегда 
означает возможность получения этой субъект-сессией всех подчинённых данной роли 
ролей. 

На уровне мандатного управления доступом с информационными потоками по памяти 
МРОСЛ ДП-модели в функции ехесиіе_сопіаіпег дополняется одно из её условии: 

Условие 3. Существует гі в Н ІІ АН, такая что (з,г,геасІ) еАА и (е,ехесиіе) в РА(гі), верно [і(еі)« 
или ССНІ(еі)=(аІзе],[(е(еі)«(з(з) или ССН(еі)=ІаІзе], где 1 «і«п. 

Определение 2.13. Пусть определены функции уровней конфиденциальности (1и,1е,1г,із) и 
мандатных атрибутов конфиденциальности ССН, (іи,іе,іг,із),ССНІ,А,АА, Р, Нг,Не,Нз,сопзігаіпі 
пг)- состояние системы. 

НІ={ѵѵгііе, 1 /т^-множество видов информационных потоков (по памяти и по времени); 
Е_НОІ-Е=НѴѴ_НОІ-Е і! 1/1/_/-/0/.Р-множество специальных объектов-дырок, где НѴѴ_НОІ-Е- 
объекты дырки первого вида, которые по определению не могут быть использованы для 
создания информационных потоков, 1/1/_ЯО/.Е-объекты-дырки второго вида, которые по 
определению не могут быть использованы для создания информационных потоков по 
памяти, Н\/Ѵ_НОіЕ (У ѴѴ_НОІЕ=0; 

Хотя мандатное управление доступом в МРОСЛ ДП-модели по дуется без применения 
ролей, задание уровней конфиденциальности ролей необходимо для предотвращения 
использования прав доступа ролей для создания запрещённых информационных потопов по 
времени [15, 17]. Например, добавляя или удаляя права доступа к сущностям у некоторой 
роли, т. е. «записывая» в неё некоторые данные, кооперирующие субъект-сессии, 
находящиеся на различных уровнях доступа, могут осуществлять передачу данных из 
сущностей с высоким уровнем конфиденциальности к сущностям с низким уровнем 
конфиденциальности. В связи с этим дано следующее определение. 

Определение 2.14. Доверенную субъект-сессию назовём корректной относительно 
информационных потоков по времени, когда она не участвует в их реализации. При этом 
используем обозначения: 

\-Ез С /.$- множество доверенных субъект-сессий корректных относительно информационных 
потоков по времени, Л ІЕз с /_5 — множество доверенных субъект-сессий некорректных 
относительно информационных потоков по времени, при этом по определению справедливы 
равенства /_Р ІІ Л/Р5=;/_Р5 ІІ Л/Р5=/_5. 

Всегда предполагается, что недоваренные субъект-сессии могут участвовать в реализации 
информационных потоков по времени (являются относительно них некорректными). 



Обеспечить в ОССН корректность доверенных субъект-сессий относительно информаци¬ 
онных потоков по времени не всегда возможно. Например, если доверенная субъект-сессия 
(коммуникационный процесс) всегда осуществляет передачу данных из одной сущности 
(входящего сокета) в другую (исходящий сокет), то она будет принимать участие в ре¬ 
ализации информационных потоков по времени с использованием этих сущностей. 

2.4.2. Условия корректности мандатного управления 
доступом и правила преобразования состояний 

В системе на уровне мандатного управления доступом с информационными потоками по 
памяти МРОСЛ ДП-модели сформулированы условия, определяющие порядок: 

•задания текущего уровня доступа субъект-сессии; 

•задания уровня конфиденциальности сущности, учёта при этом вида её метки; 

•задания уровня конфиденциальности роли, запрещающей роли или административной 
роли; 

• задания уровней конфиденциальности параметрически ассоциированных с учетной 
записью пользователя или ролью сущностей. 

• создания или удаление сущности, жёсткой ссылки на нее, получение доступа к ней 
изменения прав доступа ролей, запрещающих ролей или административных ролей к ней. 

• создание или удаления роли запрещающие роли или административной роли .получение 
доступа к ней, изменение прав доступа административных ролей к ней, изменение иерархии 
ролей администрирование функций необходимого обладания запрещающей ролью; 
•создания, удаления субъект-сессии, изменения ее роли-владельца; 

•задания уровней конфиденциальности мандатного атрибута конфиденциальности ССВ 
сущностей .ролей, запрещающих ролей и административных ролей; 

В системе на уровне мандатного управления доступом с информационными потоками по 
времени МРОСЛ ДП-модели дополнительно сформулированы и скорректированы условия, 
определяющие порядок: 

• доступа к специальным сущностям-объектам из множества ЯІ/1 1_НОіЕ; 

• создания или удаления сущности, «жёсткой» ссылки на неё, изменения прав доступа ролей, 
запрещающих ролей или административных ролей к ней, переименования сущности-контей¬ 
нера; 

•администрирования роли, запрещающей роли или административной роли, получения 
доступа к ней, использования ролей для создания информационных потоков, администриру¬ 
ют функции необходимого обладания запрещающей ролью, лучения её значения; 

• задания индивидуальных административных ролей, индивидуальных ролей четной записи 
пользователя и общих ролей, их запрещающих ролей; 



•получение доступов субъект-сессии к индивидуальным ролям и общим ролям их 
запрещающих ролям; 

•получение параметров сущностей, субъект-сессий, ролей, запрещающих ролей или 
административных ролей; 

•администрирование учётных записи пользователь .получения их параметров; 

•нарушение правил мандатным управления доступом с использованием специальной 
административной роли сІоѵѵпдгасІе_асІтіп_гоІе. 

Пример иерархии индивидуальных ролей учетных записей пользователей, заданных на 
уровне мандатного управления доступом с информационным потоками по времени МРОСЛ 
ДП-модели, для случая, когда І_С={0,1}х2(решетка уровней конфиденциальности их двух 
элементов линейной шкалы и двух неиерархических категорий, задаваемых маской из двух 
битов),приведёт на рис. 2.2. 
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Рис.2.2. Пример иерархии индивидуальных ролей учетной записи пользователя 











На уровнях мандатного управления доступом МРОСЛ ДП-модели не задаются новые де-юре 
правила преобразования состояний (их, как на предыдущем уровне, 38). Вместе с тем 
условия и результаты их применения существенно дополнены. Для примера рас. смотрим те 
же, что и на уровне мандатного контроля целостности де-юре правила видов 
ассез_геасІ(х,х,у) и зе1_епИ1у_ІаЬеІз(х,х’,у,уі). При этом для каждого правила в табл. 2.4 в 
первой строке укажем его параметры, условия и результаты применения, наследованные без 
изменений с уровня ролевого управления доступом, во второй строке — с уровня мандатного 
контроля целостности, в третьей строке — добавленные на уровне мандатного управления 
доступом с информационными потоками по памяти, а в четвёртой строке — внесённые в них 
дополнения и изменения, соответствующие уровню мандатного управления доступом с 
информационными потоками по времени. 

При получении доступа на чтение с использованием де-юре правила вида ассез_геад(х,х’,у) 
дополнительно требуется, чтобы уровень конфиденциальности у должен быть не выше 
текущего уровня доступа х. При этом на четвёртом уровне в правило не вносится никаких 
изменений. 

В де-юре правиле вида зе1_еп1Ну_1аЬе1з(х, х', у, ус, уі) дополнительно требуется наличие у 
субъект-сессии х административного доступа на чтение к специальной административной 
роли доѵѵпдгас]е,адтіп_гоІе. При этом текущий и устанавливаемый уровни конфи¬ 
денциальности сущности у не должны превосходить уровней конфиденциальности всех 
сущностей-контейнеров, в которых непосредственно находится у, и, наоборот, должны быть 
не ниже уровней конфиденциальности всех сущностей, непосредственно входящих в у Когда 
у всех сущностей, подчинённых сущности у, метки косвенные и к ним не имеют доступов 
субъект-сессии, то их уровни конфиденциальности устанавливаются равными новому 
значению этого уровня для сущности у. В связи с усложнением на уровне мандатного 
управления доступом с информационными потоками по временя иерархии индивидуальных 
ролей учётных записей пользователей и общих ролей в правило кроме условия для случая, 
когда сущность у является объектом-«дыркой» из множества ЯІ/1 1_НОіЕ (тогда ее уровень 
конфиденциальности не может быть изменён с минимального значения), в результатах 
применения правила требуется, чтобы в случае, когда у сущности у изменяется уровень 
конфиденциальности, и правом доступа к ней обладает какая-либо индивидуальная роль 
учётной записи пользователя или общая роль, то это право доступа( а также права доступа 
всех подчиненных сущности у сущностей, если все их метки косвенные)должно быть 
передано другой соответствующей индивидуальной или общей роли. В ОССН это может быть 
реализовано автоматически в случае, когда для сущности 
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Пример де-юре правил преобразования состояний МРОСЛ ДП-модели на 
мандатного управления доступом 

Таблица 2.4 
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Окончание табл. 2.4 


указывается не идентификатор соответствующей роли, а она определяется, исходя из уровня 
конфиденциальности сущности и либо из идентификатора учётной записи пользователя, 
либо из принадлежности к общим ролям. 

Единственным де-факто правилом преобразования состояний, условия которого по 
существу изменяются на уровне мандатного V управления доступом с информационными 
потоками по памяти МРОСЛ ДП-модели, является правило вида іаке_ассезз_оѵѵп{х, у, г). В 
правило этого вида также вносятся изменения на последующем уровне модели. Поэтому для 
примера рассмотрим де-факто правило вида іаке_ассезз_оѵѵп(х, у, г), а также вида 
розі(х,у,і). При этом в табл. 2.5 для каждого из них в первой строке укажем его условия и 
результаты применения, наследованные без изменении с уровня мандатного контроля 
целостности, во второй строке с уровня мандатного управления доступом с 
информационными потоками по памяти, а в третьей строке внесённые в них дополнения и 
изменения, соответствующие уровню мандатного управления доступом с информационными 
потоками по времени. 

Дополнительным условием де-факто правила вида іаке_ассезз_оѵѵп(х, у, 2 )является 
требование в случае, когда недоверенная субъект-сессия у через соответствующую роль 
обладает к субъект- сессии г правом доступа владения, то необходимо, чтобы либо текущий 
уровень доступа у был равен текущему уровню доступа г, либо наличие у субъект-сессии у 
административного доступа на чтение к административной роли доѵѵпдгасіе_асітіп_гоІе. А на 









последующем указывается, что создается информационных потоки по времени между 
субъект-сессиями хиг. 

Исходное состояние С 


Результирующее 
состояние С 


Іакеиассезв,огѵп(х , у, г) 

6 Ыз, у, * 6 5 , у € І'-Іасіо.оьті*), \іе./асіо.сѵт’(х) = іс^іо.ои^ 


х ) и 


и е <*е./ас*о.огуп(у)) или Мг) ^ і*(у), 
существует г € Ди ЛЯ: (У> г * геа< ^») ^ 

6 ЛЛ, (г, огупт ) € РЛ(г), и не сущест¬ 
вует пг 6 ДЯ: (У. *»*. геа <*°) € АА ' 
щупг) € РЛ(пг)) 

если 2 $ іе^асіо.оит{у), то / л (г) — /я(у) 
или (у, іоѵтдгайе.аітіп.гоіе, геайа) € 

€ ЛЛ 


и {*} 


|/г' = Ги{(х, 2 , гугаіее), (г,х, гупіе*] 

рояі(х, у, г) 


2 6 5, у € ( Ё\Е.НОЬВ ), X 3 * 2 , (х, у, 
шііе т ) е Г (у, геа<іо) € сіе./асіо.ассез- 

5е 5 (г) 


Т’' = РУ{(х, г, гупівт) 


у е Еи5и Ди ДДи ля (х,у,а/) е Р, 

гдеа^ 6 {гуггіе,,,. гупіе^}, [(у € (Д \ 

\ тлоьЕ) ипи ыви АПя (у, &,) € 

е 5 (г), где /З а € Да), или |и то 

у е <іе/осіо оит( 2 ))] 



если а/ = щпіе т , 0 О = геай* и 
у е Е\ Е-НОЬЕ, то Г = ДѴ) і(т. 
2, гугЧівт)}, иначе если х, г € >5 и 
/г' = Ду{(х, 2 , ѵпІеО) 


Примеры де-факто правил преобразования состояний МРОСП ДП-модели на уровнях 
мандатного управления доступом 

Таблица 2.5 

Отличия в условиях и результатах применения де-факто правила вида разІ(х,у, 2 ) 
заключается, во-первых, в том, что роли, запрещающие роли или административные роли 
могут быть источниками или приемниками информационных потоков по времени, во-вторых, 
для создания информационных потоков не могут использоваться доступы объектам-дыркам 
принадлежащим множеству ПѴѴ_НОІ_Е, в-третьих для создания таких информационных 
потоков могут примениться любые фактические доступы к сущностям или фактическое 
владение субъект-сессиями. 

Так же, как на предыдущих уровнях, на уровнях мандатного управления доступом МРОСЛ 
ДП-модели можно доказать утверждение, аналогично утверждению 2.1,о корректности 
задания де-юре и де-факто правил преобразования состояний. 
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Примеры информационных потоков по времени при применении де-факто правил 
де_ іа сіо_ор(з, ор (х,х\ ■ ■ ■) 

Таблица 2.6 

2.4.3 Достаточные условия безопасности системы в смысле Белла-ЛаПадулы 

Рассмотрим сначала условия нарушения безопасности системы на уровне мандатного 
управления доступом с информационными потоками по памяти МРОСЛ ДП-модели .Для 
этого заполним ряд определение предыдущего уровня и определим нарушение безопасности 
системы во втором смысле(в смысле Белла-ЛаПадулы). 

Определение 2.15 Назовём траекторию системы на которой доверенные субъекты-сессии 
не инициирует выполнение де-юре правил преобразование состояние, доверенные 
субъекты-сессии , обладающий текущей административной роли ,не инициирует выполнение 
де-юра и де-факто правил, траектории и без кооперации доверенных и не доверенных 
субъект-сессий. Таким образом по определению в системе на траекториях без кооперации 
доверенных и недоверенных субъектов цессии для передачи прав доступа доверенный 
субъект-сессии, не обладающие текущей административной ролью, могут инициировать 
выполнение только де-факто правил. 

Определение 2.16. Начальное состояние Оо системы (0’,ОР,Оо)назовем безопасным, когда 
оно удовлетворяет следующим условиям. 

Условие 1. Для каждых субъект-сессий х,у I 8о таких что у I де_[асІо_оѵѵп(х ), верны 
неравенства (з(у)=(з(х) и ізо(у)«ізо(х). 

Условие 2.Для каждых не доверенной субъект-сессии х е ЕО,таких что либо (е^ [у] и 
(х,е,\ ѵ/гііе) 

Условие 3. Для каждой доверенной субъект-сессии у е /_зо верное условие (у,і_еп1Ну,ті1е) 
АО. 

Определение 2.17. Пусть Оо безопасное начальное состояние системы I (О’, ОР , Оо)., и 
существует траектория без кооперации доверенных и недоверенных субъект-сессий 














00,01 ..Оп,где N>>1. Будем говорить, что в состоянии Оп произошло нарушение 
безопасности системы в смысле Белла-ЛаПадулы, когда существует информационный поток 
по памяти (х, у, ѵѵгііе) € Рп такой, что х, у € Ел и не верно неравенство (п(х)«(п(у) и это условие 
не выполняется в состояниях Оі, траектории, где 0 «і< N. Назовём систему I (0\ ОР, Оо)., 
безопасной в смысле Белла-ЛаПадулы, когда в ней невозможно соответствующее нару¬ 
шение безопасности. 

Проанализируем условия определения 2.16 и 2.17. Выполнение заданных в первом 
определении дополнительных требований к начальному состоянию обеспечивает отсутствие 
в нем недоверенных субъект-сессий, фактически владеющих субъект-сессиями с 
использованием получения контроля над такими субъект-сессиями с использованием 
сущностей,параметрически или функционально с ними ассоциированными, либо имеющих 
возможность с использованием специальной административной роли сІоѵѵпдгасІе_асІтіп_гоІе 
нарушать правила мандатного управления доступом. Также в начальном состоянии не 
должно быть запрещенных информационных потоков по памяти от сущностей или субъект- 
сессиями с низким уровнем конфиденциальности или текущим уровнем доступа. Отсутствие 
таких потоков по памяти является основополагающими требованием к ОССН , реализующей 
мандатное управление доступом (соответствие этому требованию часто называют ее 
безопасно 74 в смысле Белла-ЛаПадулы). Появление таких потоков является, нарушением 
безопасности в смысле определения 2.17, при ли, запрещающие роли и административные 
роли в соответствии с результатами применения де-факто правил преобразования состояний 
не могут являться источниками или приемниками информационного потоков по памяти. В 
результате безопасное по определению 2.16 начальное состоянии системы является 
безопасным в смысле Белла-ЛаПадулы (в нем не происходит нарушение безопасности в 
указанном смысле). 

Можно доказать теорему о том, что при безопасном начальной состоянии системы 
достаточным условием безопасности системы в смысле Белла-ЛаПадулы (не происходит 
нарушения безопасности в смысле определения 2.17) является контроль над сущностями, 
функционально или параметрически ассоциированными с субъект-сессиями, а также 
безопасность системы в смысле мандатного контроля целостности (не происходит 
нарушения безопасности в смысле определения 2.12), достаточные условия которой, 
обоснованные в теореме 2.1, остаются верными на рассматриваемом уровне модели. 
Теорема 2.2 (базовая теорема безопасности — БТБ-ДП). Пусть Оо — безопасное 
начальное состояние системы I (О’, ОР , Оо ).Пусть на всех траекториях системы без 
кооперации доверенных или недоверенных субъект-сессий 0’,0р,0о, где Ы» 0, и в каждом 
состоянии Оп для каждой субъект-сессии з вЗп и сущности е Е Ел выполняются следующие 
условия. 



Условие 1. Если е е[з], то выполняются условия і(з)«і(е), и (і(з)=і(е). 

Условие 2. Если е Е [з],то верно (п(з)=(п(е)=іп(з)«іп(е) и для каждой роли или 
административной роли г Е Нп II Аг. 

Условие 3. Для всех субъект-сессий з Е 5п таких что і_Іоѵѵ<іп(з ), выполняется равенства 
(_соггесі (з)=5п х (Еп і! Зп) (это условие является более строгим чем аналогичное условие в 
теореме 2.1, так как в нем для противодействия запрещенным информационном потокам по 
памяти требуется функциональная корректность субъект-сессии с текущим уровнем 
целостности выше минимального относительно всех.) 

Условие 4. Для всех субъект-сессий з Е Зп выполняется равенства {з’Е Зп.іп(з)=Іп(з)}. 
Тогда на этих траекториях система I (О’, ОР, Оо ) безопасна в смысле мандатного контроля 
целостности и Белла-ЛаПадулы (не происходит нарушения безопасности системы в смыслах 
определений 2.12. и 2.17). 

Условия теоремы 2.2 требуют от ОССН функционально и пара метрически корректной 
(абсолютно корректной) реализации субъект-сессий и задания соответствующих уровней 
конфиденциальности и целостности функционально или параметрически ассоциированных с 
ними сущностей. Если, например, субъект-сессия, имеющая высокий текущий уровень 
доступа, некорректно обрабатывает данные («заражается») в сущностях с низким уровнем 
конфиденциальности, и это приводит к получению фактического владения над нею субъект- 
сессией с низким текущим уровнем доступа, то система защиты ОССН не всегда сможет 
этому воспрепятствовать. Кроме того, условие 4 требует реализации в ОССН изоляции 
(невозможности создания информационных потоков по памяти с использованием 
функционально или параметрически ассоциированных сущностей) субъект-сессий 
(процессов) друг от друга, в том числе когда они обладают одинаковыми уровнями доступа. 
Таким образом, условия теоремы указывают на необходимость повышения качества разра¬ 
ботки прикладного ПО для ОССН. В условиях 1, 2 также сформулированы дополнительные 
требования к де-юре правилам преобразования состояний системы, создающим субъект- 
сессии (при этом задаются сущности, параметрически или функционально с ними 
ассоциированные), создающим сущности, изменяющим права доступа к ним или их 
параметры, так как эти сущности могут оказаться функционально или параметрически 
ассоциированными с субъект сессиями. 

2.4.4.Достаточные условия безопасности системы в смысле информационных 

потоков по времени 

На уровне мандатного управления доступом с информационными потоками по времени 
МРОСЛ ДП-модели в определении безопасного состояния дополняется только одно из 
условий. 



Определение 2.18. Начальное состояние Оо системы I (О’, ОР , Оо ) назовем безопасным, 
когда оно удовлетворяет условиям 1-3,5 определения 2.16 и выполняется следующее 
условие. 

Условие 4. Для каждого информационного потока (х,у,а) е Ро, г де , а е {тііе т,тіІе I}. 
Определим нарушение безопасности системы в третьем смысле( в смысле контроля 
информационных потоков по времени) 

Определение 2.19. Пусть Оо безопасное начальное состояние системы I (О’, ОР , Оо ),и 
существует траектория без кооперации доверенных и недоваренных субъект-сессий 
Ѳ’,Ор,Ѳо, где N1» 1.Будем говорить, что в состоянии произошло нарушение безопасности 
системы в смысле контроля информационных потоков по времени, когда в нём существует 
информационный поток по времени (х,у,ѵѵгі1е) € Рп такой, что х, у € Еп и не верно неравенство 
1п(х)«(п(у) и это условие не выполняется в состояниях 01 траектории, где 0 «і< N. Назовём 
систему I (О’, ОР , Оо ), безопасной в смысле контроля информационных потоков л по 
времени, когда в ней невозможно соответствующее нарушение безопасности. 

Это определение описывает случай реализации запрещённого информационного потока 
«сверху вниз» по времени между сущностями. Хотя роли или административные роли могут 
являться источниками или приёмниками информационных потоков по времени, для 
нарушения безопасности требуется создание именно информационного потока по времени 
между сущностями. Это объясняется тем, что в ОССН источником конфиденциальных 
данных являются только сущности и для вывода таких данных используются также сущности 
(например, файлы, устройства вывода). 

Можно доказать теорему о том, что при безопасности системы в смысле мандатного контроля 
целостности и Белла-ЛаПадулы (в смыслах определений 2.12 и 2.17) и при безопасном её 
начальном состоянии (в смысле определения 2.18) достаточным условием ее безопасности 
в смысле контроля информационных потоков по времени (в смысле определения 2.19) 
является отсутствие в системе сущностей из множества ѴѴ_НОІ_Е, которые возможно 
использовать л • создания информационных потоков по времени, а также сущностей- 
контейнеров с мандатными атрибутами конфиденциальности и целостности равными Іше, в 
состав которых входят сущности с меньшим уровнем конфиденциальности. 

Теорема 2.3. Пусть Оо-безопасное начало состояние системы I (О’, ОР , Оо ),(в смысле 
определения 2.18.)Пусть на траектории системы без кооперации доверенных или 
недоверенных субъект-сессии 00,01 ..Оп,где N>>1 .каждое состояние Оі безопасно в смыслах 
определений 2.19.Тогда в состоянии Оп не происходит нарушения безопасности системы в 
смысле определения 2.1.9,когда выполняется следующие условия. 

Условие І.Не существует субъект-сессии х Е А/зт ІІ Л/Ри сущности у Е УѴ_НОІ-Е таких что 
(х,у, тііе) ЕАт. 



Условие 2. Не существует сущности-контейнера с еСи сущности е е Ет таких что 
ССРт(с)=ССРІт(с)=ігие,где 1«М«М. 

Из теоремы следует, что для предотвращения запрещённых информационных потоков по 
времени «сверху-вниз» в ОССН достаточно обеспечения её безопасности в смыслах 
определений 2.12 и 2.17, исключения создания (особенно при установке или админист¬ 
рировании ОССН) сущностей-контейнеров с мандатными атрибутами конфиденциальности и 
целостности равными Ігие, в состав которых входят сущности с меньшим уровнем 
конфиденциальности, а также либо полный запрет на использование сущностей из мно¬ 
жества 1/1 1_НОіЕ ('задание ѴѴ_НОІ-Е=0), либо такую реализацию этих сущностей, когда их 
нельзя будет применять для создания информационных потоков времени. 

При разработке уровней мандатного управления доступом с контролем информационных 
потоков по памяти и по времени иерархического представления МРОСЛ ДП-модели для 
СУБД РозІдгеЗОЦрмс. 2.1) использовался подход, аналогичный применённому на 
соответствующем уровне мандатного контроля целостности СУБД РозІдгеЗОІ- а именно, 
уровни конфиденциальности назначались элементам СУБД до схем включительно. Кроме 
того, для предотвращения запрещённых информационных потоков по времени, во-первых, 
потребовался запрет на использования механизма передачи роли СУБД права на 
дальнейшую передачу привилегии (использованием права ѴѴІТН СЯ/4А/7 ОР7/ОЛ/), во- 
вторых, отсутствие функций СУБД, содержащихся в сущностях-схем. имеющих высокий 
уровень целостности и уровень конфиденциальности выше минимального. 

В заключение главы отметим, что научные подходы по переводу описания иерархического 
представления МРОСЛ ДП-модели с математического языка на формальный язык Еѵепі- 
Ддедуктивной верификации модели и верификации ее реализации посредственно в 
программном коде ОССН, кратко излагавшийся в предыдущем издании учебного пособия 
[4],теперь подробно рассмотрены в монографии [33]. 

Контрольные вопросы 

1. Из каких уровней состоит иерархическое представление МРОСЛ ДП-модели, 
ориентированное на моделирование маринизма управления доступом в ОССН? 

2. Как и почему менялась структура иерархическое представление МРОСЛ ДП-модели по 
мере ее разработки? 

3. Как типичные для ОС семейства Ипих с дискреционным управлением доступа три группы 
прав доступа (права владельца, группы владельца ,для всех остальных) к сущностям могут 
быть выкрадены с использованием ролей, заданных в рамках МРОСЛ ДП-модели? 

4. Для моделирования каких важных для практики случаев в МРОСЛ ДП-модели заданы 
прямые и косвенные метки сущностей-контейнеров? 



5. какие функции интерфейса механизма управления доступом ОССН, основанном на І_іпих 
Зесигііу Мосіиіе (І_5М), соответствуют де-юре правилам МРОСЛ ДП-модели? 

6. Какие учетные записи пользователей или субъект-сессии (процессы) ООСН являются 
доверенными или недоверенными? 

7. Какие сущности ООСН могут рассматриваться как функционально и параметрически 
ассоциированные с учетными записями пользователей или субъект-сессиями процессами? 

8. Что в ООСН целесообразно считать фактическим владением недоверенной субъект- 
сессией доверенной субъект-сессии? 

9. Для чего в МРОСЛ ДП-модели используются специальные административные роли из 
множества ЗАР? Какая из этих ролей самая «опасная»? Какие им могут быть найдены 
аналоги из реализованных в ООСН привилегий? 

10. В чем отличие де-юре и де-факто правил преобразования состояний? 

11. Какие ситуации в ООСН можно считать соответствующими каждому из де-факто правил? 

12. Для чего используется специальная сущность і_епМу? 

13. Почему допускается несоответствия между уровнем конфедициальности и уровнями 
конфиденциальности сущностей , к которым она обладает правами доступа, и, наоборот, 
такое несоответствие не разрешается для уровни целостности? 

14. Как зависит порядок доступа к сущности-контейнеру от значений её атрибута 
конфиденциальности ССР и целостности ССРІ? Конфиденциальности и целостности 
.соответствующим уровням этой учетной записи пользователя? 

15. Какие параметры файловой системы ООСН могут быть потенциально использованы для 
создания запрещённых информационных потоков по времени «сверху-вниз»? 

16. Какие сущности ООСН могут быть включены во множества РѴѴ_НОІ_Е или ѴѴ_НОІ_Е? 

17. Почему в МРОСЛ ДП-модели для сущностей , параметрически ассоциированных с 
учетной записью пользователя , требуется равенство их уровней 

18.Обеспечение безопасности в каком из смыслов, указанных в определениях 2.12,2.17 и 
2.19, для ОССН является основной ее безопасности в целом? 

19. Как можно доработать условия и результаты применения де-юре и де-факто правил 
МРОСЛ ДП-модели, чтобы в них были учтены условия теорем 2.1,2.2 и 2.3? 

20. Какие подходы используются при моделировании управления доступом в СУБД 
РозІдгеЗОІ- ? 

21 .Для чего МРОСЛ ДП-модель разрабатывается как единая модель механизма управления 
доступом для ОССН и СУБД РозІдгеЗОІ? 



3 Управление безопасностью ОССН 


3.1. Мандатное управление доступом 
3.1.1. Проблемы реализации мандатного управления доступом 

в операционных системах. 


В главе 1 были рассмотрены основные способы администрирования в ОССН, 
унаследованные от традиционного для ОС семейства Ипих механизма 
дискреционного управления доступом. Как известно, данный механизм позволяет 
явно разрешать или запрещать те или иные доступы субъектов к сущностям, но не 
позволяет управлять информационными потоками, содержащими информацию 
различных уровней конфиденциальности. Например, после того как данные из 
некоторой сущности прочитаны процессом (субъект-сессией), он потенциально может 
записать их в любую другую сущность, доступную ему на запись, и механизм 
дискреционного управления доступом не сможет этому воспрепятствовать. 
Аналогично, если полномочия учётной записи пользователя, от имени которой 
выполняется процесс, позволяют воспользоваться электронной почтой, то 
прочитанные данные могут быть направлены на любой адрес сети Интернет. Таким 
образом, отсутствие при использовании механизма дискреционного управления 
доступом чётких понятных всем пользователям ОССН правил обработки 
конфиденциальной информации может являться причиной для её утечки. 

По этой причине базовым при реализации защиты в ОССН стал построенный на 
основе уровней мандатного управления доступом с информационными потоками по 
памяти и по времени иерархического представления МРОСЛ ДП-модели механизм 
мандатного управления доступом. Несмотря на ряд неоспоримых преимуществ этого 
механизма, его эффективное применение в ОССН возможно только при понимании 
особенностей настройки и знании типичных ошибок реализации мандатного 
управления доступом в современных многопользовательских многозадачных 
распределенных ОС. Среди многих пользователей таких ОС распространено 
убеждение, что ман- 
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датное управление доступом (к тому же реализованное на основе устаревшей модели 
Белла-ЛаПадулы [17, 103]) — своеобразная «серебряная пуля», позволяющая 
избавиться от утечек конфиденциальных данных раз и навсегда. Это неверно, 
мандатное управление доступом не создаёт абсолютно непреодолимой защиты, 
существует целый ряд стандартных приёмов его обхода, рассмотрим некоторые из 
них. 

Нарушитель может попытаться найти в ОС сущность, в которую возможна запись данных, но 
не входящую в область действия мандатного управления доступом. Например, такая 
сущность может оказаться в каталоге временных файлов Птр, быть одним из файлов аудита 
(Іодфайлом) или по ошибке стать частью какого-либо файла настроек ОС (по аналогии с 
файлом записей реестра ОС семейства МісгозоП ѴѴІпсІоѵѵз). 

Нарушитель может постараться найти возможность для реализации информационного 
потока по памяти, не контролируемого или некорректно контролируемого механизмом 
защиты ОС. Наиболее часто такие информационные потоки обнаруживаются в графических 
подсистемах современных ОС, средствах отладки приложений, низкоуровневых средствах 
взаимодействия процессов. 

Потенциально возможна реализация нарушителем попыток создать информационный поток 
по времени с применением совместного доступа контролируемых им разноуровневых 
субъект-сессий (процессов) к одной сущности или использованием параметров ОС, 
общесистемной статистики [15]. Несмотря на кажущуюся простоту, такие информационные 
потоки заблокировать крайне трудно. 

Практически все реализации мандатного управления доступом поддерживают специальную 
привилегию, позволяющую уполномоченной субъект-сессии нарушать правила мандатного 
управления доступом (в МРОСЛ ДП-модели такая ситуация соответствуют наличию у 
субъектсессии текущей специальной административной роли (с!оѵѵпдгасІе_асІтіп_гоІе). Эта 
привилегия должна использоваться только доверенными субъект-сессиями, но иногда 
нарушителю удаётся найти уязвимость, позволяющую получить её недоверенной субъект- 
сессией. Например, в большинстве ОС(отличных от ОССН), реализующих концепцию 
суперпользователя (гооі), захват нарушителем его полномочий автоматически влечёт за 
собой преодоление всей системы мандатного управления доступом. 

Реализация перечисленных приёмов для каждой конкретной ОС требует нахождения и 
последующей эксплуатации её концептуальных или алгоритмических уязвимостей. 
Разработка системы 
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мандатного управления доступом, не содержащей уязвимостей и не позволяющей 
реализовать ни один из перечисленных или аналогичных подходов, возможна лишь 
теоретически. Например, на практике можно либо значительно затруднить создание 
нарушителем рассмотренных запрещённых информационных потоков, либо сделать 
их пропускнуюспособность очень низкой. Поэтому кратко рассмотрим наиболее 
существенные проблемы, стоящие перед разработчиками системы мандатного 
управления доступом. 

Двунаправленные информационные потоки. В формальныхмоделях безопасности 
мандатного управления доступом [17, 105] часто предполагают, что контролируемые 
информационные потоки являются однонаправленными. Если, например, субъект-сессия 
читаетсодержимое некоторой сущности, то данные передаются только в одну сторону — от 
сущности к субъекту, но не наоборот. В рассмотренных в рамках МРОСЛ ДП-модели де- 
факто правилах вида і\оѵѵтетогу_ассезз(х, у, а а ), Иоѵѵ-ііте_ассезз(х, у) и де_іасіо_ор(з, ор(х, 
х', . .. )) (когда его параметром ор(х, $', .. .) является де-юре правило вида ассезз_геасІ(х, х', 
у)) доступ или право доступа на чтение могут использоваться только для создания 
информационных потоков по памяти или по времени от сущности к субъект-сессии. На 
практике это условие верно, если сущность является, например, файлом локальной 
файловой системы ОССН, но может нарушаться при обращении к сетевым файлам и 
некоторым другим сущностям. 

Низкоуровневая техническая реализация доступа на чтение может предполагать, что запрос 
на чтение передаётся от субъекта к сущности по тому же самому каналу связи, что и ответ на 
него. Тогда разрешённому информационному потоку на чтение от сущности с низким 
уровнем конфиденциальности к субъекту с высоким уровнем доступа предшествует 
запрещённый информационный поток в обратном направлении. Заметим, что данное 
противоречие не являетсяотличительной особенностью программной реализации 
мандатного управления доступом, оно проявляется и в безмашинном, бумажном 
документообороте (всякий раз, когда, например, осуществляется обращение к источнику 
неконфиденциальнойинформации, сам факт такого обращения может рассматриваться как 
утечка информации). 

Рассмотрим пример. Пусть процесс с высоким уровнем доступа обращается на чтение к 
файлу, имеющему низкий уровень конфиденциальности и расположенному на удалённом 
сервере, доступ к которому осуществляется посредством протокола ТСР. Для иници- 
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атора запроса этот запрос не противоречит правилам мандатного управления 
доступом и должен быть выполнен. Но низкоуровневая программная реализация 
запроса в ядре ОС предполагает отправку серверу пакета, содержащего запрос на 
установку ТСР-соединения, и поскольку этот пакет исходит от процесса с высоким 
уровнем доступа, он тоже получает высокий уровень конфиденциальности. Если 
процесссервер, которому адресован запрос, имеет низкий уровень доступа, он не 
сможет прочитать данный пакет и соединение не будет установлено. Если же процесс- 
сервер имеет высокий уровень доступа, то соединение будет успешно установлено, 
но все данные, передаваемые процессомсервером, тоже будут иметь высокий 
уровень конфиденциальности. 

В современном мире разработка сложного ПО ведётся с использованием 
механизмов инкапсуляции, когда высокоуровневый про- граммный код прикладного 
или системного ПО абстрагируется от особенностей реализации функций 
низкоуровневым программным кодом. В рамках данной парадигмы прикладное ПО не 
должно учитывать, на каком носителе, локальном или сетевом, размещается 
читаемый им файл. Реализуемый в ПО алгоритм должен работать одинаково и для 
локального диска, и для удалённого сервера. Мандатное управление доступом в 
общем случае нарушает эту парадигму. В результате разработчикам мандатного 
управления доступом приходится либо перерабатывать и адаптировать значительную 
часть прикладного ПО, либо мириться с тем, что некоторые запрещённые 
информационные потоки в ряде случаев всё-таки могут быть реализованы. 

Проблемы совместимости с прикладным ПО. Часто сложное системное или 
прикладное ПО требует особой доработки для обеспечения корректного функционирования 
в ОС, реализующей мандатное управление доступом. Все ПО, входящее в дистрибутив 
ОССН, подвергается такой доработке, однако в случае установки в ОССН дополнительных 
программных пакетов Ипих могут возникать ошибки. Например, если некоторый текстовый 
редактор для своей работы требует одновременного доступа на чтение и запись к нескольким 
его конфигурационным файлам (словарей, стилей, настроек графического интерфейса и 
т.д.), то его работа с документами различных уровней конфиденциальности может привести 
к многочисленным ошибкам и сделать невозможным использование )того редактора. 
Присвоение уровней конфиденциальности системным и служебным сущностям. В рамках 
МРОСЛ ДП-модели рассмат- 
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ривались примеры особенных системных сущностей ОССН (например, файлов 
/деѵ/пиІІ или /деѵ/гего), к которым доступ на чтение и запись должен предоставляться 
субъект-сессиям (процессам), имеющим различные уровни доступа. В противном 
случае, большая часть пользовательского и системного ПО ОССН утратило бы свою 
работоспособность. В связи с этим пришлось описать особый порядок доступа к этим 
сущностям, что усложнило как саму модель, так и её реализацию непосредственно в 
ОССН. 

Таким образом, выявление таких сущностей в ОССН, поиск путей их 
безопасного использования является самостоятельной сложной задачей, стоящей 
перед разработчиками ОССН. 

Асинхронный ввод-вывод. В ядре современных ОС (например, ОС семейства МісгозоП 
ѴѴІпсІоѵѵз) большинство операций ввода-вывода выполняются асинхронно, при этом 
низкоуровневые компоненты ОС, как правило, не владеют информацией о том, в контексте 
какого запроса выполняется та или иная операция ввода- вывода. Часто затруднительно 
даже определить, каким субъектом доступа инициирован тот или иной фрагмент запроса. 
Если ОС поддерживает только дискреционное управление доступом, это несущественно — 
права доступа субъекта проверяются до начала выполнения запроса, а в ходе выполнения 
запроса они изменяться не могут. Но если в ОС реализовано мандатное управление 
доступом, состоявшийся доступ субъекта к конфиденциальной информации может 
потребовать отменить одну или несколько асинхронных операций ввода-вывода, 
выполняющихся в данный момент. 

В ОС семейства Ипих, а значит, и в ОССН, асинхронный ввод-вывод применяется 
ограниченно, и используемые для этого программные интерфейсы сравнительно просты. Их 
адаптация к правилам мандатного управления доступом не создаёт серьёзных проблем. 

3.1.2. Реализация мандатного управления доступом в ОССН 


Как уже отмечалось, основной задачей, решаемой мандатным управлением доступом в 
современных защищённых ОС, является не полное блокирование каналов утечки 
конфиденциальной информации, а существенное затруднение их реализации нарушителем. 
Даже если в ОССН имеются уязвимости, позволяющие в определённых условиях нарушать 
правила мандатного управления доступом, само наличие этих правил позволяет заметно 
повысить защищённость ОССН, поскольку: 
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• многократно снижается риск случайной утечки конфиденциальных данных в 
результате ошибочных действий пользователя ОССН. Большинство известных 
подходов к преодолению мандатного управления доступом предполагают 
выполнение нарушителем сложной последовательности неочевидных действий, 
которые нельзя выполнить случайно; 

• нарушитель, преднамеренно преодолевающий систему мандатного управления 
доступом, должен затратить значительные усилия на исследование системы, поиск 
уязвимостей, разработку методов их эксплуатации. В результате вредоносное ПО, 
разрабатываемое для реализации утечки конфиденциальных данных в популярных 
ОС, в условиях мандатного управления доступом ОССН практически 
неработоспособно; 

• сложные действия нарушителя, направленные на обход мандатного управления 
доступом ОССН, должны выявляться её развитой системой аудита или 
блокироваться организационными мерами защиты. 

Для реализации сложных моделей управления доступом в большинстве ОС 
семейства Ипих применяется пакет Зесигііу Епііапсед Ипих (ЗЕНпих) 

[136]. В ОССН данный пакет не используется по следующим причинам: 

• внесение большого объёма программного кода пакета ЗЕНпихв ОССН предполагает 
существенный объем работ по его верификациии проверке корректности 
функционирования, при этом для каждой новой версии пакета ЗЕНпих эти работы 
должны повторяться заново; 

• средства формального описания политик безопасности, реализуемые в пакете ЗЕНпих, 
крайне неудобны для теоретического исследования и описания практически значимых 
детализированныхполитик безопасности. Не вызывает сомнений, что мандатнуюполитику 
безопасности, базирующуюся на устаревшей модели Белла-ЛаПадулы, можно построить 
средствами пакета ЗЕНпих, но практическая реализация данной задачи сталкивается с 
серьёзными затруднениями. Говоря неформально «все знают человека, который знает 
человека, который видел хорошую мандатную политику для пакета ЗЕНпих, но саму эту 
политику никто не видел»; 

• пакет ЗЕНпихие имеет встроенных средств для реализации в защищаемой ОС мандатного 
контроля целостности. Эти средства могут быть созданы с использованием его 
низкоуровневых механизмов, но практическое решение данной задачи столкнёт- 
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ся с серьёзными трудностями как на этапе разработки ПО, так и на этапе научного 
обоснования корректности его функционирования; 

• большинство прикладного и системного ПО, предназначенного для выполнения в ОС 
семейства Ипих, требуют особой под- стройки для совместимости с пакетом ЗЕНпих 
(за исключением вырожденных случаев, когда средствами пакета ЗЕНпих 
реализуются тривиальные политики безопасности). 

Реализация мандатного управления доступом в ОССН основана на подсистеме 
безопасности РАРЗЕС, самостоятельно разработанной АО «НПОРусБИТех», и 
включающей соответствующие программный интерфейс и модуль расширения ядра 
ОССН, поддерживающий виртуальную файловую систему /рагзесіз и набор 
системных вызовов, позволяющих уполномоченным пользователям управлять 
политикой безопасности ОССН. Помимо мандатного управления доступом, 
подсистема безопасности РАРЗЕС также реализует мандатный контроль целостности 
и дополнительные функции аудита. На рис. 1 показано место подсистемы 
безопасности РАРЗЕС в архитектуре ОССН и порядок её взаимодействия с другими 
компонентами ОССН. Модуль РАРЗЕС устанавливает в ядре ОССН собственные 
обработчики контролируемых информационных потоков, которые получают 
управление всякий раз, когда необходимо принять решение, следует ли разрешить 
или запретить то или иное обращение субъект-сессии к сущности. Эти обработчики 
функционируют автономно, непосредственное взаимодействие модуля РАРЗЕС с 
другими компонентами 



Рисунок 2. Архитектура подсистемы защиты ОССН 
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Рисунок 3.Архитектура модуля РАНЗЕС 


вующей политике безопасности или модифицирует эту политику. Рис 2 иллюстрирует 
внутреннюю архитектуру модуля РАВЗЕС. 

Прикладное и системное ПО реализуют взаимодействие с модулем РАВЗЕС (в 
части касающейся мандатного управления доступом) через шесть системных 
вызовов: 

• зуз_сЫЫ — назначает сущности с указанным именем указанную мандатную метку; 

• зуз_{сЫЫ — назначает сущности с указанным дескриптором указанную мандатную 
метку; 

• зуз_з!аІІЫ — получает мандатную метку сущности с указанным именем; 

• зуз_ШаІІЫ — получает мандатную метку сущности с указанным дескриптором; 

• зуз_зе1ІЫ — назначает выполняющемуся процессу с указанным идентификатором 
( РЮ) указанную мандатную метку; 

• зуз_деіІЫ — получает мандатную метку выполняющегося процесса (субъекта) с 
указанным РЮ. 

Файл Іеіс/рагзес/ тас_ІеѵеІз содержит перечисление поддерживаемых в данном 
экземпляре ОССН наименований мандатных уровней, например: 
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Несекретно: О 

ДСП:1 

Секретной 

В файле /еіс/рагзес/тас_саіедогіез перечисляются поддерживаемые в данном 
экземпляре ОССН наименования неиерархических категорий, например: 

Космос: О 

Ядерная_энергия: 1 

При реализации в ОССН неиерархические категории представляются битовой маской, 
в которой каждая категория представле на одним разрядом. 

В приведённом примере политики безопасности используются неиерархические 
категории «Космос» и «Ядерная энергия». Возможные в данной политике значения 
битовой маски неиерархических категорий имеют следующий смысл: 

О (не установлен ни один бит) — информация, хранящаяся в данной сущности, не 
имеет отношения ни к космосу, ни к ядерной энергии; 

1 (установлен только бит в разряде 0) — информация, хранящаяся в данной 
сущности, имеет отношения к космосу, но не к ядерной энергии; 

2 (установлен только бит в разряде 1) — информация, хранящаяся в данной 
сущности, имеет отношения к ядерной энергии, но не к космосу; 

3 (установлены биты в разрядах 0 и 1) — информация, хранящаяся в данной 
сущности, имеет отношение и к космосу, и к ядерной энергии. 

Таким образом, в ОССН непосредственно определяется решёткамногоуровневой 
безопасности, которая в рамках МРОСЛ ДПмодели обозначена через (ГС, 
<=).Мандатные атрибуты, назначенные конкретным учётным записям пользователей, 
перечисляются в каталоге / еІс/рагзес/тасдЬ. Для каждой учётной записи 
пользователя, которой указан ненулевойи мандатный уровень или непустой перечень 
неиерархических категорий,создаётся текстовый файл, имя которого совпадает с иісі 
учётной записи пользователя. Файл включает в себя единственную строку вида 

<изетате>:<тіп_ІеѵеІ>:<тіпсаІедогіез>:<тах_ІеѵеІ>:<тах_саІедогіез>, где: 

• изегпате — имя учётной записи пользователя; 

• тіп_ІеѵеІ — минимальный мандатный уровень, доступный процессам от имени 
учётной записи пользователя; 
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• тіпсаіедогіез — числовое значение битовой маски, задающее минимальный 
набор неиерархических категорий, установленных для данной учётной записи 
пользователя; 

• тах іеѵеі — максимальный мандатный уровень, доступный процессам от имени 
учётной записи пользователя; 

• тахсаіедогіез — числовое значение битовой маски, задающей максимальный 
набор неиерархических категорий, установленный для данной учётной записи 
пользователя. 

Файл /еіс/рагзес/тас содержит строку аналогичного формата для суперпользователя гооі, по 
умолчанию равную: гоо/: 0:0:0:0 

Для всех перечисленных файлов и каталогов в каталоге / еіс/ зесигііу имеются указывающие 
на них ссылки: 

• /еіс/зесигііу/тас указывает на /еіс/рагзес/тас/; 

• /еІс/зесигіІу/тас_саІедогіез указывает на /еІс/рагзес/тас_ саіедогіез, 

• /еІс/зесигіІу/тас_ІеѵеІз указывает на /еІс/рагзес/тас_ІеѵеІз. Мандатные атрибуты текущего 
сеанса работы пользователя с 

ОССН хранятся в файле ІІіоте/%изетате%/.тас_іпІо в формате 
<ІеѵеІ>:<саІедогу>, где: 

• <ІеѵеІ> — числовое значение мандатного уровня текущего сеанса; 

• <саІедогу> — числовое значение битовой маски иерархических категорий, назначенных 
текущему сеансу. 

Мандатные метки сущностей ОССН по умолчанию распределяются следующим образом. 
Корневому каталогу / назначается наивысший мандатный уровень,поддерживаемый в 
текущем экземпляре ОССН (по умолчанию 3), в битовой маске неиерархических категорий 
устанавливаются все биты, устанавливаются атрибуты ССЛ/Я и ССЛ/Я/. Данный набор 
настроек фактически указывает, что в файловой системе ОССН могут храниться любые 
сущности с любыми мандатными метками, при этом мандатный уровень сущностей не может 
превосходить максимально возможного значения, назначенного каталогу /. Кроме того, 
благодаря наличию атрибутов ССЛ/Я и ССЛ/Я/ процесс с любым уровнем доступа, даже 
минимальным, может обратиться внутрь корневого каталога /. 

Системным каталогам /Ып, /Ьооі, /еіс, /ІіЬ, /НЬ32, /НЬ64, /Іозі +(оипсІ, /тесііа, /тпі, /орі, /ргос, 
/гооі, /зЫп, /зеііпих, /згѵ, /зуз, /изг назначается нулевой мандатный уровень и пустая (нулевая) 
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Рисунок 4. Задание уровней доступа и конфиденциальности для ОССН 

«Настройки» главного пользовательского меню. Интерфейс этой утилиты интуитивно 
ясен, при этом большинство её функций доступны только учётным записям 
пользователей, входящим в группу азІга_адтіп. 

Используемые в ОССН уровни доступа и конфиденциальности определяются в 
разделе «Мандатные атрибуты / Уровни» (рис.З). 

Каждому уровню соответствует числовое значение, чем оно больше, тем более 
конфиденциальной считается информация,отнесённая к данному уровню. 
Администратор ОССН может создавать или удалять уровни, а также редактировать 
наименование уровня — произвольную текстовую строку, используемую 
приложениями при отображении сущностей, отнесённым к данному уровню. 
Наименование уровня не оказывает никакого влияния на порядок обработки 
информации, отнесённой к нему. 

Неиерархические категории определяются в разделе «Мандатные атрибуты / 
Категории», например, так, как показано на рис. 4. 

Назначение учётной записи пользователя уровня доступа и набора неиерархических 
категорий (задание функции Р(и): і!> /.С в МРОСЛ ДПмодели) осуществляется во 
вкладке «Дополнительные» раздела 

«Пользователи и группы / Пользователи / Локальные пользователи» (рис. 3.5). 
Назначение элементов окна вполне очевидно. Выбирать ненулевые минимальные 
значения не рекомендуется. 
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Рисунок 5. Пример задания иерархических категорий 


В примере на рис. 5 процессы, выполняющиеся от имени учётной записи 
пользователя зес имеют доступ ко всем сущностям ОССН любого мандатного уровня 
конфиденциальности, но не имеют доступа к сущностям с неиерархической 
категорией «Космос». По умолчанию все мандатные атрибуты учётной записи 
пользователя имеют нулевые значения, что запрещает его процессам всякий доступ 
к сущностям, содержащим данные, отнесённые к любой неиерархической категории. 



Рисунок 6. Назначение учётной записи пользователя уровня доступа и набора иерархических категорий 
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Рисунок 7. Задание привелегий для администрирования мандатного управления доступом 


При необходимости параметры мандатного управления доступом можно назначать не 
только учётным записям «физических» пользователей, но и учётным записям системных 
пользователей (их часто называют псевдопользователями), предназначенных для 
обеспечения функционирования ОССН. Делать это без веских причин нерекомендуется, 
назначение ненулевых уровней доступа учётной записи системного пользователя может 
привести к непредсказуемому поведению процессов, выполняющихся от её имени. 

С администрированием мандатного управления доступом в ОССН связано девять 
привилегий, устанавливаемых в разделе «Привилегии» отдельно для каждой учётной 
записи пользователя (рис. 6). Данные привилегии имеют следующее назначение: 

• рагзес_сар_зеІтас — разрешает изменять мандатные уровни доступа и 
неиерархические категории процессов и назначать им привилегии (аналогом 
этой привилегии в МРОСЛ ДП-модели является специальная 
административная роль зиЬіесіз_асІіпіп_гоІе при использовании её совместно 
с административной ролью сіоѵѵпдгасіе_асІтіп_гоІе); 

• рагзес_сар_сЬтас — разрешает изменять мандатные уровни 
конфиденциальности и неиерархические категории сущностей. Может 
назначаться учётным записям пользователей, уполномоченным исправлять 
ошибочно присвоенные значения этих параметров. Если, например, файл с 
неконфиденциальным содер- 







Управление безопасностью ОССН 


203 


жимым ошибочно помечен мандатной меткой «секретно», исправить эту ошибку без 
привилегии рагзес_сар_сІітас затруднительно (аналогом этой привилегии в МРОСЛ 
ДП-модели является специальная административная роль епіШез_адтіп__гоІе при 
использовании её совместно с административной ролью доѵ/пдгаде_адтіп_гоІе); 
рагзес_сар_ідптасМ — отключает для учётной записи пользователя правила 
мандатного управления доступом в части, касающейся уровней доступа. Может 
временно назначаться учётным записям пользователей для устранения проблем, 
вызванных некорректным определением политики мандатного управления доступом. 
Если, например, действующая политика привела к тому, что файлы пользовательской 
конфигурации получили ненулевые уровни конфиденциальности, устранить эту 
проблему без временного назначения пользователю данной привилегии 
затруднительно. Привилегия рагзес_сар_ідптасМ предназначена только для 
временного применения, не следует назначать её никаким учётным записям 
пользователей на постоянной основе — она фактически отключает мандатное 
управление доступом для этих учётных записей, тем самым создаётся брешь в 
безопасности ОССН (возможности, предоставляемые этой привилегией, в МРОСЛ 
ДПмодели даёт специальная административная роль (сІоѵѵпдгасІе_асІтіп_гоІе); 
рагзес_сар_ідптассаі — отключает для учётной записи пользователя правила 
мандатного управления доступом в части, касающейся неиерархических категорий. 
Аналогично рагзес__сар_ідптасМ, эта привилегия предназначена только для 
временного применения при устранении проблем, вызванных некорректной 
настройкой политики мандатного управления доступом (эти возможности в рамках 
МРОСЛ ДП-модели также даёт специальная административная роль 
с!оѵѵпдгасІе_асІтіп_гоІе); 

рагзес_сар__зід — позволяет посылать процессам сигналы, игнорируя правила 
управления доступом, используется только для системных пользователей ОССН (не 
должна назначаться учётным записям «физических» пользователей); 
рагзес_сар_геас!зеагсІі — позволяет игнорировать правила мандатного управления 
доступом при чтении файлов и каталогов, но не при записи. Предназначена для 
использования при резервном копировании данных, к которым пользователь, 
выполняющий копирование, может не иметь доступа при других обстоятельствах; 
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рагзес_сар_тас_зоск — разрешает изменять мандатные уровни 
конфиденциальности и неиерархические категории сокетов. Используется для 
обеспечения работоспособности самой ОССН, в связи с этим не следует назначать 
её никаким учётным записям «физических» пользователей; 

рагзес_сар_ипзаіе_зеІхаІІг — разрешает изменять мандатные метки сущностей 
безотносительно мандатных меток каталогов, в которых эти сущности размещаются. 
Используется только для системных пользователей ОССН (не должна назначаться 
учётным записям «физических» пользователей); 

рагзес_сар_зитас — разрешает одновременное выполнение в одном сеансе работы 
пользователя процессов, имеющих различные мандатные метки (в МРОСЛ ДП- 
модели такая возможность предусмотрена при использовании де-юре правила 
вида сгеа№_Лг51_5е8з1оп(х, х', и, у, і, т.с, іі)). Пользователи, не обладающие 
данной привилегией, не могут пользоваться опцией «Выполнить с другим мандатным 
уровнем» утилиты «Выполнить команду». Не рекомендуется назначать эту 
привилегию пользователям без явной необходимости, так как её использование 
может создать условия для возникновения запрещённых информационных потоков 
по времени. 

Как уже упоминалось в главе 1, пользователь ОССН, начиная сеанс работы с ОССН, 
указывает мандатные уровни доступа и неиерархические категории для предстоящего 
сеанса в окне сразу после ввода корректных его имени и пароля (рис. 7). 

Элементы окна имеют следующее назначение: 

«Уровень конфиденциальности» — мандатный уровень доступа, заданный по 
умолчанию для всех субъект-сессий (процессов) начинающегося сеанса. 

выбор атрибутов б* ЮГШ МОСТИ (ЮС) 

Уромиь«ом*цд»«имЛкиостн ||^НННЮ|НИН|Н 


Рисунок 8. Окно ввода параметров мандатного управления доступом при входе пользователя в оссн 
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«Уровень целостности» — «Низкий» для непривилегированных (недоверенных) 
сеансов, «Высокий» для доверенных сеансов, в которых предполагается менять 
конфигурацию ОССН, устанавливать, конфигурировать или удалять пакеты ПО, и т. 
д. (подробно администрирование мандатного контроля целостности в ОССН будет 
рассмотрено в следующем разделе). 

«Категория» — набор неиерархических категорий процессов сеанса. 

Данное окно выводится только в том случае, если учётной записи пользователя 
доступно несколько различных мандатных уровней доступа или неиерархических 
категорий. Если выбор пользователя предопределён, окно не выводится. Началу 
сеанса работы пользователя в ОССН в рамках МРОСЛ ДП-модели соответствует 
применение де-юре правила вида сгеаіе_Тігзі_зеззіоп(х, х\ и, у, г, хс, хі). 

После входа пользователя в ОССН числовое значение 



пара- метров мандатного управления доступом для 


процессов текущего сеанса выводится в правом нижнем 

углу Э кранаУ ве Д° млений ) внутри 

квадрата, цвет которого 
(области соответствует этому 
уровню (рис. 3.8). 


Рисунок 9. Вывод параметров 
мандатного управления доступом 
текущего сеанса 


Альтернативный способ получить текущие параметры мандат- ного управления 
доступом для процессов сеанса основан на использовании команды рф-ісі (рис. 9), 
которой в МРОСЛ ДП-модели соответствует деюре правило деі_зиЬіесі_аііг(х, у, х). 
Типичным для данной команды является её использование со следующими 
параметрами: 

• рф-ісі — выдать все параметры мандатного управления доступом и уровень 
целостности сеанса в текстовом представлении; 




й 


ідіа9б$Ігв16бцфи5І1Ѳ '.*•$ рсір * 1 0 ~С 
і<ЗіАвб$Іга 16 аиди* 11 Ѳ'~І | 


Рисунок 10.Примеры применения команды рдр-ід 
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ѵайІт@ѵабІ»а5Ігв~$ рзтас 15540 
15540 Несекретно. Нет 
ѵайіт@ѵаОІеааІга. рзтас 0 
15895 Несекретно Нет 
ѵаоітвѵаРівазІга Л) | 


рф-ісІІ — выдать только мандатный уровень доступа в числовом представлении; 
рдр-ідіп — выдать только мандатный уровень доступа в текстовом представлении; 
рдр-ісіс — выдать только битовую маску неиерархических кате горий в числовом 
представлении; 

рдр-ідсп — выдать только перечень неиерархических категорий в текстовом 
представлении. 

Ещё один способ получить параметры мандатного управления доступом текущего 
сеанса — команда тасісі, которая считается устаревшей, и в будущих версиях ОССН 
её поддержка может быть прекращена.Синтаксис команды тасісі аналогичен 
синтаксису команды рсір-ісі за исключением того, что команда тасісі не выдаёт данных 
о текущем уровне целостности. 

Получить мандатные атрибуты конкретного процесса 
позволяет команда рзтас (рис. 10). Параметром 
которую необходимо получить. Специальное значение Рисунок 11 
0 позволяет получить мандатные атрибуты текущего 
процесса (т. е. самой выполняющейся команды рзтас). 

При наличии привилегии рагзес__сар_зеІтас команда рзтас позволяет 
модифицировать мандатные атрибуты процессов. 

Допускаются следующие варианты её применения: 

рзтас <рісІ> <уровень>:<категория> — назначить указанному процессу указанные 
мандатные атрибуты; 

рзтассі <рід> — эквивалентно рзтас <рід> 0:0. 

Ручное управление мандатными атрибутами процессов предназначено только для 
отладки реализованного в ОССН мандатно но для пользователей нецелесообразно. 
Штатно пользователь на протяжении всего сеанса работает с данными одного и того 
же мандатного уровня конфиденциальности и набора неиерархических категорий. Все 
описываемые далее операции по управлению подсистемой мандатного управления 
доступом ОССН не предназначены для повседневной работы, они выполняются лишь 
в редких случаях, когда возникает необходимость «перекатегорировать» те или иные 
данные, уточнить или модифицировать действующую политику безопасности и т. д. В 
обычных 
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Рисунок 12. Администрирование параметров мандатного управления доступом файла 


условиях пользователям нет необходимости явно управлять подсистемой мандатного 
управления доступом, пользователь может сконцентрироваться на текущей работе, 
не задумываясь о действующих правилах безопасности. 

Просматривать мандатные параметры файлов удобнее всего с помощью графической 
утилиты «Менеджер файлов» через выбор в контекстном меню для файла раздела 
«Свойства» и вкладки «Мандатная метка» (рис. 11). 

Заметим, что выполнение данной операции считается доступом к файлу на чтение и, 
следовательно, завершается успешно только в том случае, когда выполняющему его 
процессу доступ на чтение к файлу не запрещён ни дискреционным, ни мандатным 
управлением доступом. 

Обычно пользователь может только просматривать, но не редактировать параметры 
мандатного управления доступом файла. Но если учётной записи пользователя 
предоставлена привилегия рагзес_сар__сІітас, то процесс, выполняющийся от его 
имени, может как просматривать, так и редактировать параметры мандат- ного 
управления доступом, не выходя, однако, за пределы мандатного уровня доступа и 
набора неиерархических категорий, установ- 
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ти-гіггу-і— 1 ѵабіж ѵабіа Насакратио : Высокий . Нет 0x8 а 
-гм*»*—г—а— I ѵабіа ѵабіа Несекретно высокий 1 М#т 8ч0 в 7і 

Ігмхгѵхгыха-’ 1 ѵабіа ѵабіа Несекретно Высокий Нет: сспгі Ое$Нор -> 0е*Нор$/0е*к 

бгех--а-- 6 ѵабіа ѵабіа Несекретно высоки0 Нет сспгі ОееМор» 

бгехг-хс'хв-- 2 ѵабіа ѵабіа Несекретно Высокий Нат сспгі Видео 
бг»хг-хг-хв— 2 ѵабіа ѵабіа Несекретно Высокий Нет. сспгі йокупемты 
бгехг-хг-ха-- 2 ѵабіа ѵабіа Несекретно Высокий Нет: сспгі Загрузки 
бгухг-хг-ха-- А ѵабіа ѵабіа Несекретно Высокий Нет сспгі Изображена* 

Огмхг-хг-ха-- 2 ѵабіа ѵабіа Несекретно Высокий Нет сспгі Пумка 
бгшхг-хг-ха-- 2 ѵабіа ѵабіа Несекретно Высокий Нат сспгі Обаедоступные 
бгехг-хг«ха-- 2 ѵабіа ѵабіа Несекретно Высокий Нет: сспгі Іабломы 

Рисунок 13. Пример вывода команды рдр-Із-тас 

ленного для процесса текущим сеансом. Другими словами, если 
неконфиденциальному файлу ошибочно присвоен мандатный уровень 
конфиденциальности «Секретно», то исправить эту ошибку можно только при наличии 
у процесса привилегии рагзес_сар_сІітас и только в сеансе, мандатный уровень 
доступа которого не ниже, чем «Секретно». 

Альтернативный способ получить параметры мандатного управления доступом 
сущности — команда рф-Із, которой в МРОСЛ ДП-модели соответствует де-юре 
правило вида деі_епШу_айг(х, у, г). Данная команда во всем подобна общеизвестной 
команде Із, выдающей перечень файлов и подкаталогов заданного каталога, но 
реализует дополнительный ключ командной строки — тас. В этом случае она выдаёт 
сведения о файлах в формате, похожем на формат вывода команды ІзІ (рис. 12). 

Ещё один способ получить мандатные атрибуты 

и Іе. а 

сущности — команда деіітас (рис. 13). 

•С - Не ВЫВОДИТЬ Имена Обрабатываемых Рисунок 14 

файлов и каталогов; • 5— пропускать файлы с нулевыми мандатными атрибутами. 
Обычно все процессы, запущенные от имени учётной записи пользователя, 
выполняются с параметрами мандатного управления 
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Рисунок 15. Запуск процесса с нестандартными мандатными атрибутами 


доступом, заданными в начале сеанса его работы. При необходимости пользователь 
может запустить один конкретный процесс с другими параметрами мандатного 
управления доступом, используя графическую утилиту Ну-гип, пользовательский 
интерфейс которой представлен на рис. 14. 

Элементы пользовательского интерфейса имеют следующее назначение: 

«Команда» — имя приложения вместе с командной строкой, которое следует 
выполнить. 

«Выполнить в терминале» — перед порождением нового процесса создаётся 
временный терминал, на который отображается стандартный вывод порождаемого 
процесса. Обычно графические приложения X ѴѴіпдоѵѵ Зузіет выводят на 
стандартный вывод диагностические сообщения, которые могут помочь разобраться 
в причинах происходящего, если приложение функционирует некорректно. Данная 
опция несовместима с опцией «Выполнить с другим мандатным уровнем». 
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«Выполнить с другим мандатным уровнем» — указывается мандатный уровень 
и набор неиерархических категорий, которые должны быть присвоены запускаемому 
процессу. Мандатный уровень должен быть не ниже текущего (в соответствии с 
положениями МРОСЛ ДП-модели во избежание запрещённого информационного 
потока по времени через параметры командной строки) и не должен превосходить 
максимальный мандатный уровень, доступный текущей учётной записи пользователя. 
Аналогично устанавливаемая битовая маска неиерархических категорий должна 
содержать все неиерархические категории, заданные в текущей сессии, и не 
содержать неиерархических категорий, недоступных текущей учётной записи 
пользователя. Данная опция несовместима с любыми другими опциями. Если опция 
не выбрана, используются мандатные атрибуты учётной записи пользователя, от 
имени которой выполняется процесс Ну_гип. Текущий пользователь должен иметь 
привилегию рагзес__сар_зит.ас. Указанная комбинация мандатного уровня и 
неиерархических категорий не должна быть новой для пользователя, необходимо, 
чтобы пользователь ранее хотя бы раз указал данную комбинацию при 
первоначальном входе в систему. 

«Выполнить от имени другого пользователя» — указывает идентификационные 
и аутентификационные данные учётной записи пользователя, от имени которой 
должен быть запущен процесс. Дополнительно нужно выбрать механизм, 
используемый для запуска процесса от имени другой учётной записи пользователя 
(зи или зисіо). Если опция не выбрана, используется также учётная запись 
пользователя, от имени которой выполняется процесс Ну-гип. 

«Выполнить с другим приоритетом» — указывает приоритет, назначаемый 
запускаемому процессу. Данную опцию можно использовать для понижения 
приоритетов «жадных» программ, неумеренно потребляющих аппаратные ресурсы 
компьютера. Если опция не выбрана, запускаемому процессу назначается тот же 
приоритет, что и у процесса Пу-гип. 

«Выполнить с приоритетом реального времени» — указывает, что запускаемый 
процесс должен быть выполнен с приоритетом реального времени. Данная опция не 
должна использоваться непривилегированными пользователями. При её выборе 
выдаётся сообщение, предупреждающее, что запуск процесса в данном режиме 
может привести к краху ОССН, и требующее дополнительного подтверждения. 
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Те же самые действия можно выполнить с помощью команды зитас(еіл в МРОСЛ ДП- 
модели соответствует де-юре правило вида сгеаіе_ТігзІ_зеззіоп(х, х', и, у, х, хс, хі)) со 
следующим типичным набором параметров: зитасі <тас>с <саі> [-х], где: 
тас — мандатный уровень доступа запускаемого процесса; 

саі — числовое значение битовой маски неиерархических категорий запускаемого 
процесса; 

—х— ключ, который должен быть указан, если запускается графическое приложение 
(если не указать данный ключ, системныйвызов ХОрепОізрІау, который будет 
выполнять данное приложение, завершится с ошибкой и окно приложения не сможет 
отобразиться на экране). 

Помимо файловой системы, мандатное управление доступом поддерживается в 
ОССН и для сетевого взаимодействия процессов. В сетевые пакеты протокола ІРѵ4 в 
соответствии со стандартом ПРО 1108 и ГОСТ Р 58256-2018 [13] внедряются 
мандатные метки, наследуемые от процессов, которым принадлежат 
соответствующие со- кеты. Отсутствие метки на объекте доступа является синонимом 
нулевой мандатной метки. Для ряда сетевых сервисов (сервера ІОАР , ОЛ/5, КегЬегоз 
и т.д.) необходимо обеспечить возможность их работы с клиентами, имеющими 
разный мандатный контекст безопасности, без внесения изменений в исходные тексты 
сервиса. Для предоставления данной возможности в ОССН реализован специальный 
механизм, названный ргіѵзоск. 

Управление конфигурацией данного механизма осуществляется путём 
редактирования конфигурационного файла / еіс/рагзес/ргіѵзоск.сопі 

3.1. Мандатный контроль целостности 

В настоящее время большинство успешных взломов защиты ОС реализуются с 
применением программных закладок [52] — небольших по объёму кода программ или 
фрагментов программ, которые скрытно внедряются в атакуемую систему и 
предоставляют нарушителю скрытный доступ к ресурсам атакуемой ОС, вносят 
уязвимости в её подсистему безопасности, противодействуют антивирусному ПО, 
пакетным фильтрам, системам обнаружения атак и т. д. 

Компьютерные вирусы и сетевые черви являются частными случаями программных 
закладок. 
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Степень уязвимости ОС в отношении программных закладок в основном 
определяется двумя взаимосвязанными факторами: 

насколько легко программной закладке внедрить свой программный код в 
критически важные (например, системные) области атакуемой ОС; 

насколько большие полномочия может получить внедрённая в ОС программная 
закладка в практически значимых ситуациях, Мандатный контроль целостности 
(Мапдаіогу ІпІедгНу Сопігоі — МІС) [17, 104] в основном предназначен для того, чтобы 
затруднить программным закладкам внедрение в защищаемую ОС и дальнейшее 
функционирование в ней [107]. В качестве побочного эффекта нейтрализуется угроза 
вывода ОС из строя некорректно работающим инсталлятором или деинсталлятором 
прикладного или системного ПО, ненамеренно повреждающим критически важные 
программные модули ОС (в англоязычных источниках данную угрозу обычно 
называют О/./. ІіеІІ [111]).Как правило, при реализации в ОС мандатного контроля 
целостности её сущности разделяются на несколько уровней целостности. 

В ОССН, начиная с версии 1.6, реализована решётка иерархических уровней 
целостности (в МРОСЛ ДП-модели ей соответствует решётка (И, <=)) от 0 до 255, 
каждый элемент которой является маской из 8 битов. Самыми важными элементами 
этой решётки, устанавливаемыми по умолчанию, являются уровни целостности 
«Низкий» (0) и «Высокий» (63). Кроме этих уровней целостности, которые при наличии 
соответствующих полномочий могут быть непосредственно выбраны пользователем 
для сеанса его работы, в ОССН также реализованы «промежуточные» уровни 
целостности для важных для её безопасности компонент (табл. 1). 

Таблица 1 

Уровни целостности ОССН версии 1.6 

ТаЫе 1 


Значение 

Витовая 

маска 

Комментарий 

0 

00000000 

Уровень «Низкий» (Ьоиі) 

1 

00000001 

Уровень «Сетевые сервисы» 

2 

00000010 

Уровень «Виртуализация» 

4 

00000100 

Уровень «Специальное ПО» 

8 

00001000 

Уровень «Графический сервер» 

16 

00010000 

Свободен, может быть использован для СУБД 

32 

00100000 

Свободен, может быть использован для антивируса 

63 

00111111 

Уровень «Высокий» ( НгдЬ,) 

64 

01000000 

Свободен, может быть использован для гипервизора 

128 

10000000 

Свободен, может быть использован для контроллера 
домена 
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Мандатный контроль целостности, как формально определено в рамках 
соответствующего уровня иерархического представления МРОСЛ ДП-модели, не 
допускает модификации сущностей с высоким уровнем целостности недоверенными 
процессами (субъект-сессиями) с низким уровнем целостности. Обращения 
процессов ОССН к сущностям, потенциально нарушающие их целостность (операции 
записи, перемещения или удаления, понимаемые в широком смысле вариантов их 
реализации), разрешаются только в том случае, когда уровень целостности процесса 
не уступает уровню целостности сущности, к которой он обращается. Другими 
словами, модификация низкоцелостным процессом высокоцелостной сущности 
запрещается независимо от дискреционных или мандатных прав доступа процесса к 
сущности. Модификация сущностей ОССН, важных с точки зрения её безопасности, 
разрешается только доверенным процессам, выполняющимся от имени 
привилегированных учётных записей пользователей с высоким уровнем целостности. 
Для ограничения возможностей перемещения или удаления критически важных 
сущностей присваивается соответствующий уровень целостности контейнеру, 
содержащему такие сущности. 

Процесс, выполняющийся на низком уровне целостности, не имеет возможности: 

получать доступ к процессам, выполняющимся на более высоких уровнях целостности, 
в том числе не может направлять управляющие сообщения их окнам; 

порождать процессы, выполняющиеся от имени другой учётной записи пользователя, 
с использованием механизмов зи, зисіо, зиісІ/здісІ т , 

порождать процессы, выполняющиеся на высоком уровне целостности. 

В начале сеанса работы с ОССН пользователь выбирает уровень целостности для корневого 
процесса своей пользовательской сессии. Если для сессии выбран низкий уровень 
целостности, то все процессы, выполняющиеся в ней, гарантированно выполняются на 
низком уровне целостности. 

Если нарушителю удалось выполнить свой программный код в рамках такой сессии, 
возможности нарушителя будут сильно ограничены. 

Этот код не способен ни обеспечить собственную автоматическую загрузку в следующей 
сессии того же или другого пользователя, ни эффективно скрывать своё присутствие в ОССН 
от утилит администрирования и антивирусного ПО. В результате ПО, используемое 
нарушителем и не проникшее на высокий уровень целост- 
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ности, как правило, не в состоянии причинить атакованной ОССН сколько-нибудь 
заметный долговременный ущерб. 

Заметим, впрочем, что низкий уровень целостности не ограничивает возможности ПО 
нарушителя по несанкционированному доступу к пользовательским данным, 
хранящимся и обрабатывающимся в ОССН. Если нарушитель имеет возможность 
многократно повторять внедрение программной закладки в атакуемую ОССН 
(например, эксплуатируя критическую уязвимость в её коде), наличие мандатного 
контроля целостности не создаёт нарушителю серьёзных затруднений, здесь защита 
от утечки конфиденциальных данных должна осуществляться с применением 
мандатного управления доступом. 

Большинство пользовательских сеансов должны стартовать на низком уровне 
целостности. Высокий уровень целостности следует выбирать только в том случае, 
если пользователь решает задачи администрирования системного ПО, настройки или 
конфигурирования ОССН в целом. Сеансы с высоким уровнем целостности не должны 
использоваться чаще, чем это необходимо. 

По умолчанию сеанс с высоким уровнем целостности имеет характерную «красную» 
цветовую гамму (рис. 3.15). Данная цветовая гамма не позволяет пользователю 
забыть, что он работает в потенциально опасном режиме, требующем повышен- 



Рисунок 16. Внешний вид сеанса с высоким уровнем целостности 
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Рисунок 17. Интерфейс утилиты управления подсистемой мандатного контроля целостности 


ной внимательности. Кроме того, если пользователь постоянно работает с высоким 
уровнем целостности, его коллегам становится очевидно, что он пренебрегает 
правилами безопасности. 

Для управления мандатным контролем целостности служит раздел «Мандатный 
контроль целостности» графической утилиты «Управление политикой безопасности» 
(рис. 16). 

В некоторых случаях, когда администратору безопасности ОССН необходимо 
выполнить действия по её администрированию, например установить новые пакеты, 
с помощью этой графической утилиты он может отключить мандатный контроль 
целостности. Это следует делать на минимально необходимый интервал времени, 
обеспечив при этом отсутствие в ОССН процессов, функционирующих от имени 
учётных записей пользователей (как минимум, «физических») с уровнем целостности 
«Низкий». 

В целом корректная настройка мандатного контроля целостности является 
нетривиальной задачей, требующей от администратора безопасности высокой 
квалификации и глубокого понимания особенностей функционирования 
установленного в ОССН системного и прикладного программного обеспечения. 
Заданная по умолчанию политика назначения сущностям уровней целостности 
подходит для большинства конфигураций ОССН, менять её без веских причин не 
рекомендуется. 
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3.3. Управление доступом к объектам графической подсистемы 

Длительное время ОС семейства Ипих рассматривались главным образом как 
платформы для развёртывания серверного ПО. Компоненты таких ОС, 
эксплуатируемые на рабочих станциях пользователей, в том числе и графическая 
подсистема, не обращали на себя пристального внимания ни экспертов по 
компьютерной безопасности, ни хакерского сообщества. Но для защищённой ОССН, 
ориентированной в том числе и на эксплуатацию на рабочих станциях, графическая 
подсистема является одной из наиболее важных и ответственных с точки зрения 
безопасности подсистем ОССН. 

ВОС семейства Ипих графический интерфейс реализуется с ис- пользованием 
клиент-серверной системы X ѴѴіпсІоѵѵ Зузіет. Давно известно, что данная система 
небезопасна. Например, возможность похищения процессом X ѴѴіпсІоѵѵ Зузіет 
конфиденциальных дан- ных, принадлежащих другому процессу, впервые описана в 
1994 г. Р. Браатеном [106]. В 2002 г. Дж. Фишер сформулировал основные угрозы, 
которые процесс X ѴѴіпсІоѵѵ Зузіет может представлять для других процессов [115]: 
модификация параметров сессии; 
несанкционированное создание/уничтожение окон; 
перехват оконных событий; 
навязывание оконных событий. 

Логично предположить, что за прошедшие годы перечисленные угрозы были повсеместно 
нейтрализованы, но на самом деле это не так. Во всех без исключения (кроме 
использованной в ОССН) исследованных авторами реализациях X ѴѴіпсІоѵѵ Зузіет некоторые 
важные проверки, необходимые для управления доступом пользователей к элементам 
графической подсистемы ОС, реализованы некорректно либо не реализованы вообще [60]. В 
результате непривилегированный процесснарушитель в ряде случаев может 
несанкционированно повышать свои полномочия (например, направляя в окна 
привилегированных процессов последовательности оконных событий, имитирующие 
действия пользователя), а также похищать конфиденциальные данные из окон других 
процессов (например, несанкционированно внедряя своё дочернее окно внутрь окна 
атакуемого процесса). В результате проведённых исследований было обнаружено несколько 
уязвимостей, каждая из которых может быть устранена добавлением в код X ѴѴіпсІоѵѵ Зузіет 
проверок соответствующих условий, но для полного их устранения, а также устранения 
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предпосылок к появлению новых подобных уязвимостей, нужна существенная 
переделка графической подсистемы. Важно отметить, что обнаруженные уязвимости 
носят концептуальный характер, для их устранения недостаточно внести точечные 
изменения в программный код X ѴѴіпсІоѵѵ Зузіет, в исправлении нуждаются его 
базовые концепции. 

Для того чтобы наглядно пояснить одну из многих проблем безопасности X ѴѴіпсІоѵѵ 
Зузіет, рассмотрим знаменитую атаку Зііаііег, впервые применённую для ОС 
Місгозоіі ѴѴіпсІоѵѵз в 2002 г. [1138]. В классической реализации данной атаки процесс- 
нарушитель отправляет в окно привилегированного процесса ОС сообщение о 
состоянии несуществующего таймера, обработчиком которого якобы является 
функция, которую нарушитель желает несанкционированно вызвать в контексте 
привилегированного процесса. Другая известная реализация атаки [140] находит одно 
из невидимых системных окон, незаметно создававшихся на рабочем столе в ранних 
версиях ОС Місгозоіі ѴѴіпсІоѵѵз ХР, назначает этому окну клавиатурный фокус и 
имитирует нажатие клавиши Р1. Открывается окно справки ОС, при этом 
обслуживающий его процесс і /ѵіпііірХ2.ехе запускается с полномочиями 
привилегированной учётной записи псевдопользователя ЗУЗТЕМ. Затем в данное 
окно с помощью имитации перемещения файла из окна в окно ( дгад-п-сігор ) 
загружается заранее подготовленный файл справки, содержащий внешнюю ссылку на 
приложение нарушителя, по которой сразу имитируется активизация. В результате 
программный код, предоставленный нарушителем, начинает выполняться в контексте 
привилегированного процесса. 

Атака Зііаііег основана на том, что в ОС Місгозоіі ѴѴіпсІоѵѵз 2003 и более ранних версиях окна 
двух разных процессов, размещённых на одном рабочем столе, могли обмениваться 
сообщениями фактически без ограничений. В результате во многих практически значимых 
ситуациях непривилегированные процессы могли несанкционированно повышать свои 
полномочия, направляя специально подобранные последовательности сообщений окнам 
привилегированных процессов. Каждая последовательность сообщений, приводящая к 
несанкционированному повышению полномочий, связана с отдельной уязвимостью, которую 
чаще всего несложно устранить, но до тех пор, пока сохраняется сама возможность 
управления окном привилегированного процесса из непривилегированного процесса, 
говорить о безопасности графической подсистемы не приходится. 

Похожие уязвимости были обнаружены и в X ѴѴіпсІоѵѵ Зузіет [60]. 
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В ОС семейства МісгозоІІ ѴѴіпсІоѵѵз данная проблема была в основном решена 
реализацией в ОС МісгозоП ѴѴіпсІоѵѵз Ѵізіа мандатного контроля целостности, 
дополненного контролем учётных записей (ІІзег Ассоипі СопігоІ — Ѵ\АС) [108]. При 
этом в программный код графической подсистемы ОС были включены несколько 
сотен дополнительных проверок, учитывающих мандатные уровни целостности 
процессов и сущностей при реализации самых разнообразных операций в 
графической подсистеме. Данный подход предъявляет повышенные требования к 
квалификации и аккуратности реализующих его программистов — достаточно всего 
лишь одной пропущенной проверки, чтобы в графической подсистеме появилась 
критическая уязвимость. Особенно трудно реализовать данный под- ход в ситуации, 
когда базовый функционал графической подсистемы не создан с нуля доверенным 
разработчиком, а взят из стороннего проекта, скудно документированного, не 
имеющего централизованной технической поддержки и продолжающего развиваться 
непонятным и непредсказуемым образом. 

В ОССН, начиная с версии 1.4, реализуется другой подход, ос- нованный на изоляции 
сущностей графической подсистемы, мандатные атрибуты которых отличаются от 
заданных по умолчанию, в особые сеансы, изолированные с точки зрения 
графической подсис- темы от основного сеанса работы пользователя с ОССН. В 
обычном сеансе работы пользователя таких сущностей не создаётся, они могут 
создаваться только если пользователь, обладающий привилегией рагзес_сар_зитас, 
запускает процессы с нестандартными мандатными атрибутами, используя 
графическую утилиту ііу-гип или консольную утилиту зитас. Тогда при старте 
процесса автоматически открывается новый сеанс (в терминах X ѴѴіпсІоѵѵз Зузіет — 
создаётся дисплей), и когда запущенный процесс вызывает системную функцию 
ХОрепОізріау, подключение перенаправляется на этот новый сеанс, а окно 
приложения приобретает вид, показанный на рис. 17. 



Рисунок 18. Окно приложения выполняющегося в изолированной среде 
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Окно приложения, выполняющейся в изолированной среде, от- личается от обычных 
окон следующими особенностями: 

к концу заголовка окна дописана строка «в изолированной сре- де ( сігі+д для 
захвата мыши и клавиатуры)» (заметим, что для большинства приложений захват 
мыши и клавиатуры осуществляется при необходимости автоматически и не требует 
нажатия каких-либо особых клавиш); 

цветная рамка, окружающая окно, отличается цветом от размок, окружающих 
другие окна (за исключением ситуации, когда приложение, выполняющееся в 
изолированной среде, отличается отдругих приложений только неиерархическими 
категориями, но не мандатным уровнем); 

каждое приложение, выполняющееся в изолированной среде, имеетсвой собственный 
буфер обмена ( сІірЬоагсІ ), изолированный от основного буфера обмена, позволяющего 
пересылать данные между приложениями, при этом передача данных через буфер обмена 
за пределы изолированной среды невозможна, как и приём данных изза пределов 
изолированной среды. Для помещения графических приложений в изолированную среду 
используется утилита Херііуг, создающая в ОССН полнофункциональный Х-сервер и 
проецирующая его графический вывод в одно из окон, функционирующих на основном X- 
сервере. Для графических приложений основного Х-сервера окно изолированной среды 
выглядит как монолитный графический образ. Получить внутреннюю структуру данного окна, 
используя ХОиегуТгее и другие подобные системные вызовы основного Х-сервера, 
невозможно. При запуске приложения в изолированной среде последовательно 
выполняются следующие действия: 

в основном сеансе работы пользователя, обслуживаемом основ- ным Х-сервером 
ОССН, создаётся новое окно; 

создаётся Х-сервер Херііуг, его графический вывод перенаправляется в окно, 
созданное на предыдущем шаге; 

запускается новый экземпляр оконного менеджера ІІу-ѵѵт, его подключение к X- 
серверу ( ХОрепОІзрІау ) перенаправляется на Хсервер Херііуг (это необходимо для 
корректного отображе- ния заголовка окна приложения, корректной работы некоторых 
функций графического интерфейса); 

запускается целевое приложение, его подключение к Х-серверу перенаправляется на 
Х-сервер Херііуг. Выполнение графических приложений в изолированной среде требует 40- 
50 Мбайт дополнительной оперативной памяти на каж- 
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дое такое приложение. Для сравнения, процесс ИЬге ОНісе, в кото- ром открыт пустой 
текстовый документ, расходует 110 Мбайт оперативной памяти, пасьянс ОТ с 
открытой игрой Ргее СеІІ — 90 Мбайт, калькулятор Зреед, СгипсР — 30 Мбайт. Для 
большинства современных компьютеров дополнительный расход памяти на 
погружение приложения в изолированную графическую среду совершенно незаметен. 
Однако на устаревших аппаратных платформах, а также при запуске в изолированной 
среде большого количества графических приложений производительность ОССН 
может снижаться. 

Домашний каталог, соответствующий указанной комбинации мандатного уровня и 
неиерархических категорий, а также все со- путствующие ссылки внутри папки /Роте/ .рф 
должны существовать до вызова утилиты Ну-гип. Другими словами, утилита Пу-гип позволяет 
использовать только те комбинации мандатного уровня и неиерархических категорий, 
которые не являются новыми для данной учётной записи пользователя. Первоначальная 
инициализация пользовательской среды, соответствующей определённой комбинации 
мандатного уровня и неиерархических категорий, корректно реализуется только при обычном 
входе в систему, описанном в главе 1. 

В ОССН версии 1.3 или более ранних изолированная среда вы- полнения графических 
приложений не поддерживалась. Мандатное управление доступом к сущностям графического 
интерфейса было реализовано путём внесения в программный код Х-сервера 
дополнительных проверок, не позволяющих процессам реализовывать запрещённые 
информационные потоки по памяти с использованием графического интерфейса. Начиная с 
версии 1.4, необходимость в этих проверках в значительной степени утрачена, однако 
программный код, реализующий мандатное управление доступом, не удалялся из 
графической подсистемы. В современных версиях ОССН он играет роль дополнительного 
эшелона защиты. 


3.4. Особенности аутентификации 

Подобно другим современным ОС семейства Ипих подсисте- ма аутентификации ОССН 
построена на основе архитектуры РАМ (РІиддаЫе Аиііпепіісаііоп Мосіиіез). К стандартному 
набору модулей РАМ добавлены четыре дополнительных модуля, реализующих назначение 
мандатных атрибутов, уровня целостности и специфических привилегий ОССН первому 
процессу в сеансе работы пользователя с ОССН. Если клиентское приложение РАМ в ходе 
аутентификации не обращается к перечисленным модулям, сеанс 
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Рисунок 19. Общие настройки учётной записи пользователя 


пользователя, аутентифицированного данным приложением, полу- чает низкий 
уровень целостности и нулевые мандатные атрибуты, не дающие никаких прав 
доступа к конфиденциальным данным. 

В ОССН не предъявляется никаких специальных требований к РАМ модулям. Любой 
такой модуль, разработанный для любой ОС семейства Ипих, должен корректно 
функционировать в ОССН. В файл /еіс/рат.сі/соттоп-раззѵѵогсі по умолчанию 
включён РАМ- модуль рат_сгаскІіЬ.зо, запрещающий назначать пользователям 
простые пароли, нестойкие к подбору. 

Администрирование подсистемы аутентификации осуществля- ется с 
использованием графической утилиты Ну-асітіп-зтс («Управление политикой 
безопасности»). Пароль и основные параметры аутентификации для пользователя 
задаются при регистрации его учётной записи на вкладке «Главные» элемента меню 
«Пользователи / <имя пользователям (рис. 18). 

Основные элементы вкладки имеют следующее назначение: 

Имя — имя учётной записи пользователя пользователя 
( %изегпате%). 

ІІЮ — внутренний числовой идентификатор учётной записи пользователя, 
назначается при регистрации, в дальнейшем обычно не изменяется. Указывается 
справочно, так как это может пригодиться при анализе системных журналов, 
локализации и устранении проблем функционирования системного и 
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прикладного ПО и т.п., но в повседневной работе не используется. Чаще всего 
администратор даже не знает, каким учётным записям сопоставлены какие числовые 
идентификаторы. Обычно первая зарегистрированная в системе учётная запись 
пользователя получает идентификатор 1000, вторая зарегистрированная учётная 
запись пользователя — 1001, и т.д. 

Первичная группа — группа учётной записи пользователя, внут- ренний числовой 
идентификатор которой назначается в качест- ве идентификатора ОЮ процессам, 
запускаемым от имени дан- ной учётной записи пользователя. По умолчанию каждой учёт¬ 
ной записи пользователя назначается фиктивная группа, вклю- чающая только саму учётную 
запись пользователя. Каждой учётной записи пользователя назначается одна и только одна 
первичная группа. Первичная группа не может быть одной из предопределённых системных 
групп; 

Дом. каталог — каталог, в котором будут размещаться документы и настройки данной 
учётной записи пользователя. По умолчанию имя домашнего каталога имеет вид 
/Ііоте/%изетате%; 

Переместить — указывает, нужно ли при изменении домашнего каталога переместить 
старое содержимое на новое место. Доступно только если домашний каталог только что 
изменился и изменения ещё не применены. 

Оболочка — командный интерпретатор, запускаемый в качестве командной оболочки 
(зЬеН) в текстовых терминалах, с которымиработает данный пользователь. По умолчанию 
используется командный интерпретатор /Ып/ ЬазЬ. Для учётных записей пользователей, 
которым запрещено пользоваться командным интерпретатором, данная настройка не имеет 
смысла. 

Пароль: изменить — позволяет администратору ОССН принудительно назначить 
учётной записи пользователя новый пароль. Это самый простой способ устранить проблему, 
если пользователь забыл свой пароль. 

Пароль: печатать — включает отображение учётной карточки пользователя с 
возможностью её печати. 

ОЕСОЗ — значение элемента ОЕСОЗ учётной записи 
пользователя. 

Данный элемент используется некоторым устаревшим ПО для хранения дополнительной 
информации о учётной записи пользователя (полное имя, должность, номер комнаты, номер 
телефона и т.д.), не имеет отношения к обеспечению безопасности. По умолчанию имеет вид 
«%изетате%». 
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Рисунок 20.Настройка блокировки учётной записи пользователя 


Группы — перечень групп, в которые входит учётная запись пользователя. 
Заметим, что для предоставления учётной записи пользователя административных 
полномочий необходимо и достаточно включить её в группу азіга-адтіп либо с 
помощью данной вкладки, либо сделав группу азігаадтіп первичной группой учётной 
записи пользователя. 

Чаще всего все вышеперечисленные свойства учётной записи пользователя 
однократно задаются при её регистрации и более не изменяются, однако при 
необходимости администратор ОССН может в любой момент изменить любое её 
свойство. 

Параметры блокировки учётной записи задаются на вкладке «Блокировка», вид 
которой показан на рис. 19. 

Элементы вкладки имеют следующее назначение: 

Счётчик неудачных входов — число неудачных входов в систему, которые 
пытался совершить пользователь с момента последнего обнуления счётчика 
неудачных входов либо с момента регистрации учётной записи пользователя, если 
счётчик ни разу не обнулялся. 

Сброс — кнопка обнуления счётчика неуспешных входов для данной учётной 
записи пользователя. Доступна, только если счётчик имеет ненулевое значение. 

Максимальное число неудачных попыток входа — максимально допустимое для 
данной учётной записи пользователя значение счётчика неуспешных входов. При 
превышении данного значения учётная запись пользователя автоматически 
блокируется. 

Удаление пароля и блокировка входа — разрешает блокировку входа и 
удаление пароля при превышении максимального числа неудачных попыток входа. 
Блокировать пароль — включает блокировку пароля; 

Блокировать учётную запись — включает блокировку учётной записи. 
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Рисунок 21. Настройка аудита в отношении учётной записи пользователя 


Настройки аудита в отношении учётной записи представлены на рис. 20. 

Флаг «Настройки аудита по умолчанию» включает для данной учётной записи 
пользователя настройки, заданные на вкладке «По умолчанию» раздела «Аудит» 
графической утилиты ІІу-асІтіп-зтс. Другие элементы вкладки аналогичны 
соответствующим элементам вкладки «По умолчанию» раздела «Аудит», они будут 
рассмотрены ниже. 

Вкладка «Привилегии», представленная на рис. 21, перечне- ляет привилегии, 
назначенные данной учётной записи пользователя. Слева перечислены так 
называемые привилегии Ипих, совпадающие с аналогичными привилегиями ОС 
ОеЬ/ал Ипих, справа — привилегии РАРЗЕС, специфичные для ОССН. Битовые маски 
внутреннего представления предоставленных привилегий приводятся справочно, эта 
информация может пригодиться при просмотре журналов аудита и решении 
некоторых задач администрирования ОССН. В дальнейшем привилегии в 
соответствии с МРОСЛ ДП-моделью планируется реализовать через роли, 
запрещающие роли или административные роли. 




Управление безопасностью ОССН 


225 


ЦЩІІХ 

Привилегии 0x666 



Раг*ес 

Привилегии. 0x666 


Привилегии 

Р*Ч*Д 


Привилегии 

Разряд 

? 1 сор.сіюмп 



О рвис.мр.Ій.сар 

0 

■ ( ар.Оес оѵегпОе 

1 


■ і Р»ГМС.(«Р.МСІІ( 

1 

■ свр.Оас.геаО.геагсЬ 

2 


■ раггес.сар.іеілик 

2 

О свр.Гоѵѵпег 

3 


! раг**<_(ар <Ьтас 

3 

Г) сар_1*е«іс1 

4 


1 рагік_сар_ідгѵгѵ»сМ 

4 

1 □ сар„іиН 

* 


■ раг$ес сар ідлтассаі 

5 

■ сар.якдіб 

6 


М (МЛИ.МР.ід 

6 

| О ир.мцк] 

7 


[3 рвг«е<_сдр.цр04іе.4(ѵѵ>е 

7 

О сар.іеірсар 

8 


О рдоес.сар рггѵ лоск 

8 

■1 сар.Ііл и х.іт пчііаЫе 

9 


■ рапи.Сіір.гигімгсН 

9 

■ сар_пеі_ЬіпО_*егѵ»<е 

10 


К32&ЭЕЭМНІ 

|ю 

О сар_п«і_Ьгоа<ка« 

11 


О раггес. іар тас_«хк 

11 

1 (3 сар.пвс.агітт 

12 


(3 ра«»е(_сар.ипба1е_міхаКг 

12 

( | евр.пеі.гам 

13 


О рапес.сер.ідптаот 

13 

П свр.ірс.кхк 

14 


1 рагзес.свр.гитвс 

14 

_і сар.цх.оетег 

1* 





Рисунок 22. Назначение привелегий учётной записи пользователя 


Кратко охарактеризуем привилегии Ипих: 

сар-скіоѵѵп (0) — позволяет объявлять себя владельцем любого файла или 
каталога; 

сар_сІас-оѵеггісІе (1) — позволяет игнорировать запреты дискреционного 
управления доступом к файлам и каталогам; 

сар-сІас_геасІ зеагсіі (2) — позволяет игнорировать запреты дискреционного 
управления доступом к файлам и каталогам только в части чтения и поиска 
информации; 

сар-іоѵѵпег (3) — позволяет получать дополнительные права доступа, как если 
бы учётная запись пользователя была владельцем всех файлов и каталогов; 

сар_ізеідіс! (4) — позволяет игнорировать запреты на установку битов ЗеШЮ и 
ЗеіОЮ в атрибутах дискреционного управления доступом к файлам и каталогам; 
сар_кіІІ (5) — позволяет посылать любые сигналы любым процессам; 
сар__зеІдісІ (6) — позволяет манипулировать атрибутами процесса, 

указывающими на принадлежность учётной записи пользователя, от имени которой 
выполняется процесс, той или иной группе; 

сар__зеІиісІ (7) — позволяет переназначать процессы другим учётным записям 


пользователей; 
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сар_зеірсар (8) — позволяет назначать и отменять привилегии конкретным 
процессам; 

сар_Ііпих_ітти1аЫе (9) — разрешает модификацию постоянных файлов и 
файлов «только для дозаписи» в файловых системах Ех12 и ЕхІЗ; 

сар_пеі_Ьіпд._зегѵісе (10) — позволяет привязывать сокеты к ІР-портам с 
номерами, меньшими 1024; 

сар_пе1_ЬгоасІсаз1 (11) — разрешает широковещательную и многоадресную 
рассылку сетевых пакетов; 

сар_пеі_ас!тіп (12) — позволяет администрировать сетевую под- систему 

ОС; 

сар_пеі_гаѵѵ (13) — позволяет осуществлять сетевое взаимодействие на низком 
уровне, с использованием так называемых «сырых» сокетов; 

сар_ірс_Іоск (14) — позволяет блокировать страницы и секции разделяемой 
оперативной памяти; 

сар_ірс_оѵѵпег (15) — позволяет получать дополнительные права доступа, как если бы 
учётная запись пользователя была владельцем всех объектов межпроцессного 
взаимодействия; 

сар_зуз_тос!иІе (16) — позволяет загружать и выгружать модули ядра; 
сар_зуз_гаѵѵіо (17) — позволяет получать доступ к портам ввода/вывода посредством 
системных вызовов іорегт() и і роІ(); 

сар_зуз_с!ігооі (18) — необходима для успешного осуществления системного вызова 
сЬгооЦ); 

сар_зуз_рігасе (19) — позволяет осуществлять системный вызов рігасе() в отношении 
любого процесса ОС; 

сар_зуз_рассІ (20) — разрешает настройку попроцессного учета; 
сар_зуз_асІтіп (21) — позволяет администрировать ОС (проверяется множеством 
разных системных вызовов, связанных с «обобщённым» администрированием); 

сар_зуз_ЬооІ (22) — позволяет перезагружать ОС системным вызовом геЬооЦ); 
сар_зуз_пісе (23) — позволяет назначать процессам высокие 

приоритеты; 

сар_зуз_гезоигсе (24) — позволяет манипулировать квотами распределения 
аппаратных ресурсов между процессами; 

сар_зуз_1іте (25) — позволяет менять системное время; • сар_зуз_Пу.соп!ід (26) — 
необходима для выполнения некоторых действий с текстовым терминалом; 
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сар_ткпод (27) — позволяет осуществлять привилегированные системные 
вызовы ткпосІО', 

сар_Іеазе (28) — позволяет осуществлять блокировку типа «аренда файла». 
Привилегии РАН5ЕС: 

рагзес_сар__ЯІе_сар (0) — позволяет устанавливать привилегии на файлы; 
рагзес-сар_аидіі (1) — позволяет управлять подсистемой аудита; 
рагзес_сар_зеІтас (2) — позволяет менять мандатные метки процессов; 
рагзес_сар_сІітас (3) — позволяет менять мандатные метки файлов; • рагзес- 
сар_ідптасМ (4) — позволяет игнорировать правила мандатного управления 
доступом в части, касающейся мандатных уровней; 

рагзес-сар_ідптассаі (5) — позволяет игнорировать правила мандатного 
управления доступом в части, касающейся иерархических категорий; 

рагзес_сар_зід (6) — позволяет игнорировать правила мандатного управления 
доступом при отправке сигналов процессам; 

рагзес_сар_ирсіаІе_аІіте (7) — позволяет игнорировать правила мандатного 
управления доступом при установке времени доступа к файлам; 

рагзес_сар_ргіѵзоск (8) — позволяет создавать привилегированный сокет и 
менять его мандатную метку; 

рагзес_сар_геасІзеагсІі (9) — позволяет игнорировать правила мандатного 
управления доступом только в части чтения и поиска информации; 

рагзес_сар_Сар (10) — позволяет игнорировать правила 

мандатногоуправления доступом при назначении привилегий процессам; 

рагзес_сар_тас_зоск (11) — позволяет менять мандатную метку сетевого 
соединения; 

рагсез_сар_ипзаіе_зеІхаІІг (12) — позволяет устанавливать мандатные 

атрибуты объектов файловой системы без учёта мандатных атрибутов родительского 
объекта-контейнера; 

рагзес_сар_ідптасіп! (13) — позволяет игнорировать правила мандатного 


контроля целостности; 
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рагзес_сар_зитас (14) — позволяет стартовать процессы с мандатными 
атрибутами, отличными от заданных для текущего пользовательского сеанса. 

По умолчанию никакие учётные записи пользователей не имеющих никаких 
привилегий. Не следует назначать им привилегии без веских причин, надо понимать, 
что каждое назначение привилегии создаёт в политике безопасности потенциальную 
уязвимость. 

Для управления привилегиями также могут применяться следующие утилиты 
командной строки: 

изегсарз — позволяет просматривать и устанавливать привилегии учётным 
записям пользователей; 

ехесарз — позволяет устанавливать привилегии запускаемому процессу; 
рзсарз — позволяет просматривать и устанавливать привилегии 
выполняющемуся процессу. 

Вкладка «МРД», описывающая назначение учётным записям пользователей 
мандатных атрибутов, уже была рассмотрена в этой главе. 

Вкладка «Срок действия», представленная на рис. 22, описывает параметры 
политики безопасности, связанные со сроками действий пароля и учётной записи 
пользователя. 

Элементы вкладки имеют следующее назначение: 

Минимальное число дней между сменами пароля — описывает минимальный 
интервал времени между двумя последовательными сменами пароля. Специальное 
значение 0 (задано по 

■ , Минимально* количество дней между сменами паролі 
О дней 

■ Максимальное количество дней между сменами парол 
99999 дней 

■ і Число дней выдачи предупреждение до смены пароли: 

7 дней 

Число дней неактивности после устаревание пароле 
— до блокировки учетной илжи 

0 Срок действие учетной записи пользователе 

И . 

Рисунок 23.Параметры политики безопасности, связанные со сроками действий пароля и учётной записи 

пользователя 
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умолчанию) разрешает менять пароль немедленно после предыдущего изменения. 

Максимальное число дней работоспособности пароля — описывает 
максимальный срок действия пароля, по истечении которого пароль устаревает. По 
умолчанию задан максимально допустимый для ввода в окне срок 99999 дней, что 
составляет немногим менее 274 лет и фактически отключает данную политику. 

Число дней выдачи предупреждения до смены пароля — описывает поведение 
ОССН, когда пароль учётной записи пользователя вот-вот устареет. Если значение 
данного поля равно Л/, то за Л/ дней до устаревания пароля при каждом успешном 
входе в систему пользователю выдаётся предупреждение, что его пароль скоро 
устареет. 

Число дней неактивности после устаревания пароля до блокировки учётной 
записи пользователя — описывает поведение ОССН в случае, если устаревание 
пароля произошло в период долгой неактивности пользователя, когда пользователь 
не входил в систему много дней подряд, обычно такие ситуации связаны с отпуском, 
командировкой или болезнью. Если значение данного поля равно Л/, ОССН разрешает 
единственный вход по устаревшему паролю в течение Л/ дней после устаревания, 
затем учётная запись блокируется. Специально значение — 1 (установлено по 
умолчанию) требует блокировать учётную запись пользователя немедленно после 
устаревания пароля. 

Срок действия учётной записи пользователя — устанавливает дату, по достижении 
которой учётная запись становится недействительной. 

Зелёная кнопка внизу — импортирует параметры политики из ранее подготовленного 
шаблона. 

Помимо индивидуальных настроек учётных записей, в ОССН действуют три общесистемные 
политики, связанные с подсистемой аутентификации: политика блокировки, политика 
паролей и политика создания учётных записей пользователей. Все три политики задаются в 
разделе «Политики учётных записей» графической утилиты Ну-асітіпзтс. 

Общесистемная политика блокировки учётных записей пользователей описывается в 
подразделе «Блокировка», вид соответствующего интерфейса приведён на рис. 23. 
Элементы этого интерфейса имеют следующее назначение: 

Индивидуальные настройки — разрешает или запрещает индивидуальное управление 
максимальным числом неуспешных по- 
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Г Щ Индивидуальные настройки 
Г~І Не сбрасывать счетчик 

О Не исполыоеать счетчик для пользователя с шб*0 
Л Неуспешных попыток 10 С 

Г] Период блокировки: 

Г_| Период разблокировки: 

Рисунок 24. Вид интерфейса управления общесистемной политикой блокировки учётных записей пользователей 


пыток входа для каждой отдельной учётной записи пользователя. 

Не сбрасывать счётчик — определяет порядок изменения счётчика неуспешных 
входов: при успешном входе — сбросить (обнулить) либо уменьшить на 1. 

Не использовать счётчик для учётной записи пользователя с иісі =0 — 
запрещает блокировать учётную запись суперпользователя гооі. 

Неуспешных попыток — числовое значение для максимально допустимого 
количества неуспешных входов. 

Период блокировки — длительность в секундах периода времени, когда 
запрещается повторно входить в систему после каждой неуспешной попытки входа. 

Период разблокировки — длительность в секундах периода времени, когда 
запрещается повторно входить в систему после превышения максимально 
допустимого значения счётчика не успешных попыток входа. 

Целесообразно установить период блокировки длительностью порядка несколько 
десятков секунд, период разблокировки — намного длиннее. 

Интерфейс управления общесистемной политикой паролей, за данной в подразделе 
«Политика паролей», разделяется на три вкладки. Вкладка «Сложность» 
представлена на рис. 24. Элементы вкладки имеют следующее назначение: 

Проверка имени пользователя — не позволяет использовать в качестве пароля 
имя учётной записи пользователя или простую функцию от него. 

Проверка ОЕСОЗ — не позволяет использовать в качестве пароля информацию 
из поля ОЕСОЗ учётной записи пользователя или простую функцию от неё. 
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88 Сложность Срок действия 

Шаблоны устареваі с > 

О Проверка имени пользователя 


О Проверка СЕСОЗ 


1 Применять для пользователя гооі 


Минимальная длина пароля: 


8 

Л 


Минимальное количество строчных букв в новом пароле: 


0_| Минимальное количество «главных букв 8 новом пароле: 

Минимальное количество цифр в новом пароле. 

С I Минимальное количество других символов в новом пароле. 

Рисунок 25. Параметры общесистемной политики паролей, описывабщие сложность паролей 

Применять для пользователя гооі — распространяет политику паролей на 
учётную запись пользователя гооі (по умолчанию никакие ограничения, связанные с 
безопасностью, на суперпользователя гооі не распространяются). 

Минимальная длина пароля — задаёт минимально допустимую длину пароля в 
символах. 

Минимальное число строчных букв в новом пароле, Минимальное число заглавных 
букв в новом пароле, Минимальное число цифр в новом пароле, Минимальное число 
других символов в новом пароле — накладывают ограничения на содержимое пароля, 
не позволяя применять длинные, но легкоподбираемые пароли наподобие 
«1234567890» или «ааааааааааааааааааааааааа». Вкладка «Срок действия» 
описывает параметры политики паролей, имеющие отношение к срокам действия 
паролей. Вид вклад- ки представлен на рис. 25. 

Назначение элементов вкладки вполне очевидно. Зелёная кнопка в нижней части 
вкладки импортирует параметры политики из шаблона, ранее подготовленного с 
применением вкладки «Шаблоны устаревания». Раздел, определяющий политику 
создания учётных записей пользователей, имеет вид, представленный на рис. 26. 
Элементы раздела имеют следующее назначение: 
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® Сложность Срок действия Шаблоны устареть» > 

■ Минимальное количество дней между сменами пароля: 

Одней О 

■ Максимальное количество дней между сменами пароля: 

99999 дней ^ 

■ I Число дней выдачи предупреждения до смены пароля. 

7 дней . О 

I—] Число дней неактивности после устаревания пароля 
- до блокировки учетной записи: 

О Срок действия учетной записи пользователя: 

V 

О] 

Рисунок 26. Параметры общесистемной политики паролей, описывающие срок действия паролей 


Дом. каталог — описывает каталог, внутри которого размещаются домашние 
каталоги учётных записей пользователей. По умолчанию это каталог /Ііоте, менять 
данную настройку не рекомендуется. 

Каталог шаблонов — описывает каталог, содержащий шаблоны, используемые 
для первоначального заполнения вновь создаваемых домашних каталогов файлами 
настроек (ргоіііе, ЬазМгс и т.д.). 

Оболочка — путь к файлу заданного по умолчанию командного интерпретатора. 

Первичная группа — группа, назначаемая по умолчанию первичной группой 
вновь создаваемым учётным записям пользователей. 

Настройка имеет смысл только если не установлено «Создавать новую 
пользовательскую группу». 

Создавать новую пользовательскую группу — если установлено, для каждой 
создаваемой учётной записи пользователя автоматически создаётся группа с тем же 
именем, и она назначается первичной группой данной учётной записи пользователя. 

Добавлять пользователя в дополнительные группы — если установлено, новые 
учётные записи пользователя автоматически добавляются в перечисленные ниже 
группы. 

Дополнительные группы — список групп, в которые автомати- 
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Дом. каталог /Ьоте 


Каталог шаблонов: /еіс/$кеі 


Оболочка 
Первичная группа: 


/Ьіп/Ъа&Ь 


Л Создавать новую пользовательскую группу 
■ Добавлять пользователя в дополнительные группы 


Дополнительные группы 

Изим^новзниб 

/Ч сю 

Системная 


2 ѵОес 

44 

Да 


— ікег$ 

100 

да 


— ріидгіеѵ 

46 

да 


— (Іорру 

25 

да 


ріаіоиі 

20 

да 


2 сРгот 

24 

да 


— аийю 

20 

да 


;+ 1 - 


Рисунок 27. Параметры политики создания учётных записей пользователей 


чески добавляются вновь создаваемые учётные записи пользователей. Настройка 
имеет смысл только если установлено «Добавлять пользователя в дополнительные 
группы». 

Помимо вводимых с клавиатуры паролей, в ОССН поддерживаются и другие факторы 
аутентификации: 

одноразовые пароли (скрэтч-карты); физические устройства или носители, 
предоставляющие аутентификационную информацию (смарт-карты, ІІЗВ-токены и 

др-); 

биометрическая информация. 

Для обеспечения двухфакторной аутентификации с помощью внешнего носителя 
используются следующие средства и технологии: 

РКСЗ ( РиЫіс-Кеу Сгуріодгарііу ЗіапсІагсІ) — группа стандартов криптографии с 
открытым ключом, в частности стандарты РКСЗ- 11, 

РКСЗА2, РКСЗ-15, относящиеся к работе с криптографическими токенами; 

Х.509 — стандарт, определяющий форматы данных и процедуры 

распределения открытых ключей с помощью сертификатов с цифровыми подписями, 
которые предоставляются сертифи- 
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кационными органами; 

0реп8С — набор программных утилит и библиотек работы с носителями 
аутентификационной информации учётной записи пользователя; 

ОрепСТ — набор драйверов устройств работы с носителями аутентификационной 
информации; 

ОрепЗЗЬ — программное средство для работы с криптографическимпротоколом 55/У 
ИЗ. Позволяет создавать ключи РЗА, ОН, ОЗА и сертификаты Х.509, подписывать их, 
формировать файлы сертификатов СЗН и СНТ. Также имеется возможность шифрования 
данных и тестирования 55/./ 715 соединений; 

РС/ЗС — набор спецификаций для доступа к смарт-картам; 

РКІИІТ (РиЫіс Кеу СгуріодгарЬу іог ІпіііаІ АиіЬепіісаііоп іп КегЬегоз) — стандарт 
использования криптографии с открытым ключом в качестве фактора аутентификации в 
протоколе аутентификации КегЬегоз. 


3.5. Особенности аудита 


Помимо стандартного для ОеЫап ѲМЫ/Ипих демона гзузіодсі, в ОССН также имеется 
собственная система аудита, реализуемая подсистемой безопасности РАР8 ЕС, 
позволяющая более эффективно управлять регистрацией событий, непосредственно 
связанных с безопасностью ОССН. Архитектура аудита РАНЗЕС показана на рис 27. 


Ядро ОС 


Модуль подсистемы безопасности РЛКБЕС 


Средства выборки, 
анализа и 
представления 



Рисунок 28.Архитектура аудита РАНЗЕС 


Зарегистрированные события записываются в файлы кегпеі, тіод и изег.тіод, по 
умолчанию размещаемые в каталоге /ѵаг/Іод/ 
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Рисунок 29. Интерфейс утилиты просмотра журналов аудита 


рагзес. Каждая запись файла соответствует одному зарегистрированному событию и 
содержит следующие данные: 

имя учётной записи пользователя; 
источник события; 
время регистрации события; 
имя процесса; 

статус выполнения системного вызова, приведшего к регистрации события: успех ([з]) 
или отказ ([!]); 

имя и параметры системного вызова, приведшего к регистрации события. 

Для просмотра зарегистрированных событий аудита используется графическая утилита Ну- 
асітіп-ѵіеѵѵ аисііі, интерфейс которой показан на рис. 28. 

В левой части окна интерфейса перечислены текущие параметры фильтрации 
отображаемых событий, а также файлы, доступные для просмотра. В правой части окна 
интерфейса отображаются события, зарегистрированные в выбранном файле аудита и 
удовлетворяющие текущим параметрам фильтрации. События, связанные с успешными 
обращениями к данным, отображаются белым цветом, события, связанные с неуспешными 
обращениями, — красным. 

Управление фильтрацией событий аудита осуществляется по команде меню «Фильтр / 
Изменить» с использованием интерфейса,представленного на рис.29. 

Основные элементы интерфейса имеют следующее назначение: 

Заголовок интерфейса содержит имя редактируемого фильтра. 

Время — позволяет задать интервал времени, к которому должны принадлежать 
отображаемые события аудита. Можно указать в явном виде начальный и конечный 
моменты, воспользо- 
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Рисунок 30. Управление фильтрацией событий аудита 


ваться одним из предопределённых значений либо отключить фильтрацию событий 
аудита по времени. 

Статус — позволяет фильтровать отображаемые события аудита по статусу 
выполнения системного вызова. Если в фильтре выбран только один статус, в окно 
утилиты выводятся только события аудита с этим статусом, если выбраны или не 
выбраны оба статуса, фильтрация событий аудита по статусу отключена. 

Источник — позволяет фильтровать отображаемые события аудита по 
источнику. Если в фильтре не выбран ни один источник, фильтрация по источнику 
отключена, и в окно утилиты выводятся события аудита с любым источником, так же 
как когда выбраны все три источника. 

Файлы — позволяет ограничить отображаемые события аудита определённой 
областью файловой системы ОССН. 

Дополнительные параметры — позволяет фильтровать события аудита, 
содержащие заданные подстроки в соответствующих полях 
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■] Настройки аудита по умолчанию 
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Рисунок 31. Настройка политики аудита 


События — позволяет фильтровать отображаемые события аудита по типу 
системного вызова, с которым оно связано. Политикой аудита удобнее всего 
управлять с помощью графической утилиты ІІу-асІтіп-зтс («Управление политикой 
безопасности»). 

Аналогично политикам паролей в ОССН может одновременно действовать несколько 
политик аудита. Каждая политика аудита может быть применена к конкретной учётной 
записи пользователя или к группе учётных записей пользователей, кроме того, 
существует общесистемная политика, действующая по умолчанию. Создание и 
редактирование политик аудита осуществляется в разделе «Аудит» (рис. 3.30). 
Политика аудита кодируется двумя битовыми масками, в которых каждый бит 
соответствует категории событий, регистрируемых подсистемой аудита. Одна маска 
перечисляет успешные события (т. е. события, соответствующие успешным попыткам 
доступа про- цессов к сущностям), другая — неуспешные события. Каждая категория 
событий аудита соответствует одному или нескольким сис- 
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темным вызовам, при реализации которых, если соответствующая категория 
включена, то генерируется событие аудита. В ОССН версии 1.6 реализуются 
следующие категории событий аудита: 

ореп — открытие файловой сущности (файла или каталога); 
сгеаіе — создание файловой сущности; 
ехес — выполнение исполняемого файла; 
деіеіе — удаление файловой сущности; 

сііппосі — изменение дискреционных атрибутов файловой сущности 
(типичного для ОС семейства Ипих вектора прав доступа); 
сііоѵ/п — изменение владельца файловой сущности; 

тоипі — монтирование или размонтирование внешнего носителя данных; 

тосіиіе — загрузка или выгрузка модуля расширения ядра ОССН; 

иісі — смена идентификатора учётной записи пользователя для процесса; 

дісі — смена идентификатора группы для процесса; 

аисііі — изменение политики аудита; 

асі — изменение дискреционных атрибутов файловой сущности; 

тас — изменение мандатных атрибутов файловой сущности; 

сар — изменение привилегий учётной записи пользователя или группы; 

сЬгооІ — смена корня файловой системы ОССН для процесса; 

гепате — переименование файловой сущности; 

пеі — некоторые сетевые операции. 

Каждой учётной записи пользователя и группе ОССН может быть сопоставлена своя 
политика аудита. Для создания новой политики аудита используются подразделы 
«Аудит / Группы» или «Аудит / Пользователи» соответственно. Альтернативный 
способ определить или скорректировать политику аудита для учётной записи 
пользователя или группы — открыть соответствующую вкладку «Аудит». 

По умолчанию каждый экземпляр ОССН реализует собственную политику аудита, 
хранящуюся на данном компьютере. Кроме того, поддерживается централизованное 
управление аудитом в масштабе корпоративной сети. В дистрибутив ОССН включены 
следующие средства централизованного аудита: 

оззес-ііісіз-зегѵег — сервер аудита, устанавливается на специальновыделенном 


сервере; 
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События безопасности иифорыаі** по состоя* 


> на 12 ч. 36 » 


й О а л 2 




Рисунок 32. Графический интерфейс централизованного управления аудитом просмотр зарегестрированных событий 


оззес-ііібз-адепі — агент аудита, устанавливается на каждом компьютере, на 
котором реализуется централизованное управление аудитом; 

оззес-ѵѵеЬ — графический интерфейс для управления сервером аудита (рис. 31, 
32), устанавливается на том же компьютере, что и сервер аудита, требует наличия 
веб-сервера Арасііе2 с поддержкой РНР; 

оззес-спі — средство настройки аудита для бездисковых станций. 


ПЕРЕЧЕНЬ РЕГИСТРИРУЕМЫХ СОБЫТИИ БЕЗОПАСНОСТИ ИНФОРМАЦИИ 

ШІ^ДД ІДИИИИИИИИИИИИИИИИИИМІ 



мм*. 


Рисунок 33. Гоафический интерфейс централизованного управления аудитом управление политикой аудита 
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Глава 3 


Для управления подсистемой аудита могут применяться следующие утилиты 
командной строки: 

деііаисі — получает информацию о порядке генерации сообщений аудита в 
отношении заданного файла; 

зеііаисі — устанавливает порядок генерации сообщений аудита в отношении 
заданного файла; 

изегаисі — просматривает и изменяет порядок генерации сообщений аудита в 
отношении заданной учётной записи пользователя; • рагзеіод — низкоуровневое 
средство получения структурированной информации из файлов аудита; 

кетіод — надстройка над утилитой рагзеіод, предназначенная для получения 
информации из файла /ѵаг/Іод/рагзес/кегпеі, пгііод; 

изегіод — надстройка над утилитой рагзеіод, предназначенная для получения 
информации из файла / ѵаг/Іод/рагзес/ изег. тіод; 

изегаисі — просматривает и изменяет порядок генерации сообщений аудита в 
отношении заданного процесса. 

3.6. Сетевое взаимодействие в ОССН. 

Организация доменной инфраструктуры 
3.6.1. Логические уровни сетевой инфраструктуры 

В главе 1 было отмечено, что использование ОССН в составе АСЗИ 
подразумевает организацию сетевого взаимодействия компьютеров, 
функционирующих под её управлением в составе ЗЛВС. Поскольку в качестве 
базового стека протоколов в ОССН используется стек ТСР/ІР [73, 75], методика 
создания подобных ЗЛВС основана на методике создания сетевой инфраструктуры 
на базе этого стека протоколов. При этом организация сетевой инфраструктуры может 
рассматриваться, как минимум, на двух логических уровнях: 

базовом, подразумевающем организацию сетевого взаимодействия компьютеров 
(хостов), работающих под управлением ОССН в составе одной или нескольких подсетей со 
статическим или динамическим выделением ІР-адресов, реализацией статической 
маршрутизации между хостами, входящими в разные подсети, а также организацией шлюза 
для доступа в сеть Интернет; 

корпоративном, подразумевающем организацию доменной сетевой инфраструктуры 
на базе одного из вариантов службы ка- 
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талогов (Оігесіогу Зегѵісе), обеспечивающей её пользователям механизм ЕГІГ1, включая 
централизованное управление учётными записями пользователей и групп пользователей, 
прозрачную (сквозную) аутентификацию в ЕПП с любого хоста, являющегося клиентом 
домена и централизованное хранение домашних каталогов пользователей. 

В этом случае модули ІЗМ Мосіиіе Роіісу Епдіпе подсистемы безопасности РАНЗЕС 
раздельно реализуют управление доступом (Ііоокз/сіесізіоп) для каждого из указанных 
логических уровней: І_5Ммодуль рагзес обеспечивает управление доступом на уровне стека 
протоколов ТСР/ІР (реализован для версии протокола ІРѵ4); І_5М-модуль рагзес-сііз 
обеспечивает управление доступом на уровне протокола прикладного уровня СІРЗ [72] — 
диалекта протокола ЗМВ [36] (реализован для версии протокола ЗМВ 3. 0. Очевидно, что 
корпоративный уровень сетевой инфраструктуры является оверлейным, то есть 
развёртывается только поверх базового уровня. 



3.6.2. Формирование базового уровня сетевой инфраструктуры 

ОССН 


ТаЫе 2 


агр 

Работает с таблицей АНР (АНР кэшем ядра), используемой 
протоколом АНР для преобразования !Р -адреса в МАС- 
адрес 

ііпзіотпаіппате 

Сообщает о доменном имени ОЫЗ-системы 

іотатпате 

Выдаёт или устанавливает доменное имя N13/ УР системы 
(Ыеіиюгк Іп/огтаіюп Зегхпсе/ Уеііою Радез) — службы цент¬ 
рализованного администрирования промышленных сетей 

Нозіпате 

Выдаёт или устанавливает имя хоста (сетевого узла) 

і/соп/ід 

Является основной утилитой конфигурирования сетевых 
интерфейсов 

і ртаіЛт 

Добавляет, удаляет или показывает широковещательные ад¬ 
реса сетевого интерфейса 

іріиппеі 

Добавляет, удаляет или показывает туннели, используемые 
в сетевом интерфейсе 

тіх-іооі 

Проверяет или устанавливает статус интерфейсного модуля 
МП (Месіха I пхіерепсіепі Іпіег/асе — независимый мультиме¬ 
дийный интерфейс) 

пате «/ 

Присваивает интерфейсам имена, используя при этом МАС- 
адреса 

пеізіаі 

Получает отчёт о сетевых соединениях, таблицах маршрути¬ 
зации и статистике работы сетевого интерфейса 

пхзіотаіппате 

Обладает теми же функциями, что и команда йотахппате 

ріхрсоп/хд 

Управляет параметрами протокола РЫР — передачи /Р- 
пакетов через параллельный порт (подключение компью¬ 
теров между собой соединением «точка-точка» через парал¬ 
лельные порты) 

гагр 

Управляет протоколом НАНР — удалённое получение без¬ 
дисковыми станциями /Р-адреса по МАС-адресу 

гоиіе 

Работает с таблицей маршрутизации протокола ІР 

зІаіІасН 

Подключает сетевой интерфейс к линии последовательного 
доступа (для использования терминальных линий при под¬ 
ключении компьютеров между собой соединением «точка- 
точка») 


Средства управления трафиком (качеством обслуживания) [30] 
графические утилиты, встроенные в защищённую графическую подсистему ГІу. 

Далее будут рассматриваться команды из набора пеііооіз, поскольку именно он 
рекомендуется в документации на ОССН в качестве основного средства 
администрирования базовой сетевой инфраструктуры. В текущий версии ОССН в 
набор пеі Іооіз входят команды, приведенные в табл.2. 

Для создания базовой сетевой инфраструктуры основными из представленных 
в табл. 3.2 являются команды Нсопіід, пеізіаі, агр и гоиіе. Настройка сетевых 
интерфейсов. Для настройки сетевых интерфейсов используется команда іісопіід (от 
Іпіегіасе Сопіідигаііоп 
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гооівазіга-зегѵег іТсопПд 

6(ьо I іпк слсдр:Е (Ьвгпеі нивУйг ѲѲ 0с 29 4е 79 Т9 

шеі агібг 16 Ѳ 0 2 Всазі 18 255 255 255 Мд*к:255 8 8 
ІІР 8Р0Я0СЙ5Т Риннінб МШТІСЙ5Т ПТУ 15ѲѲ Меігісі 
РХ раскеи 121 еггог$ 8 РгорраР 8 оѵвггііпз Ѳ Тга*е 8 
Тх раскеіі 76 еггогз 8 УгорреУ Ѳ оѵегпіпзв свгпег Ѳ 
со 11і5і0П5 8 Іхдиеиеіеп IѲѲѲ 

РХ Ьуіеь 18708 (18 2 Кі8) ТХ Ьуівз 13592 (13 2 Кі8) 

Іо Ііпк епсвр І.оса! ІоорЬаск 

іпеі ддбг 127 8 0 1 МазѴ 255 ѲѲѲ 

ЦР ЮОРѲЯСК Римм IНС МТУ 65536 Маіпс 1 

РХ раскеіз 18678 вггогз 8 РгорреР 0 оѵаггип* 8 Тгаве 0 

ТХ раскеі* 10678 еггогз 0 гігоррей в оѵеггцпь в саггівг 

со!Iізіопз 8 иоиаиеіеп 0 

РХ Ьуіез 1754949 (1 6 МіѲ> ТХ Ьуіез 1754949 (1 6 Мі8> 


Ѳ 


Рисунок 34. Пример вывода команды ІГсопЯд 


выполняющая следующие функции: 
назначение ІР- адреса; 

назначение широковещательного адреса и связанной с ним маски подсети; 
включение (ир) и выключение (сіоѵѵп) сетевого интерфейса. Обычно команда 
гісопіід применяется во время первоначальной настройки сети, но может 
использоваться и для внесения изменений в ходе её эксплуатации. Пример вывода 
этой команды приведён на рис. 34. 

Управлять конфигурированием сетевых интерфейсов администратор ОССН 
может не только с помощью команды гісопіід, но и с использованием графической 
утилиты «Сетевые соединения», вызываемой из главного пользовательского меню 
через меню «Панель управления» (рис. 35). Она предназначена для управления 
соста- 



Рисунок 35. Доступ к утилите "Сетевые соединения"в меню "Панели управления 
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Рисунок 36. Физические и логические сетевые соединения, поддерживаемые утилитой "сетевые соединения" 


вом поддерживаемых проводных и беспроводных физических или логических 
сетевых соединений и конфигурирования их параметров. Перечень 
поддерживаемых соединений представлен на рис. 36. В зависимости от выбранного 
типа добавляемого сетевого соединения вызывается окно его конфигурирования. 

Для большинства типов сетевых соединений существуют единые параметры, 
объединенные во вкладки «Основное» (приоритет соединения, доступ к нему 
авторизованных пользователей, использование для соединения ѴРЛ/- шлюза), 
«Прокси» (параметры конфигурирования прокси сервера, через который 
осуществляется сетевое соединение), «Параметры ІРѵ4 и ІРѵб» (параметры 
конфигурирования сетевого протокола /Р версий 4 и 6 соответственно). Примеры 
интерфейсов конфигурирования физического и логического соединений 
представлены на рис. 37. 

Также доступ к утилите «Сетевые соединения» можно получить из области 
уведомлений рабочего стола Р/у, используя меню приложения области 
уведомлений «МеіѵѵогкМападег» (рис. 38). 

Дополнительно при необходимости организации туннелирования сетевого 
соединения приложение « МеІѵѵогкМападег» позволяет вызвать меню 
предварительно настроенных Ѵ'Р/Ѵ- шлюзов. Их конфигурирование осуществляется 
либо путём вызова соответствующего интерфейса настройки нового ѴР/Ѵ- шлюза на 
основе ОрепѴРМ — свободной реализации ѴРЛ/ с открытым исходным кодом, либо 
путём экспорта настроек из сохранённых в файловой системе файлов конфигурации 
ѴРЛ/- шлюзов соответствующих ѴРЫ-провайдеров 
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Рисунок 37 


ь~ сч г уг 

Рисунок 38 


Рис. 37. Примеры интерфейсов конфигурирования параметров сетевых соединений: а — 
параметры конфигурирования физического соединения ЕШегпеі; б 
— параметры конфигурирования логического соединения (туннельное ІР- 

соединение) 



Рис. 38. Меню приложения области уведомлений «Nе^ѵѵо^кМападе^» для управления 
сетевыми устройствами соединениями 

(рис. 39). При успешном конфигурировании адресной информации сетевого 
интерфейса в области уведомлений рабочего стола Пу появится соответствующее 
сообщение об успешном сетевом подключении. 

При этом следует учитывать, что поскольку ОССН адаптирована для работы с 
мобильными устройствами, оборудованными моду- 










Рисунок 40.Интерфейс конфигурирования нового ѴРМ-соединения на основе реализации ОрепѴРИ 



Рисунок 41. Интерфейс конфигурирования нового соединения мобильной связи 


лями сотовой связи, в интерфейсе утилиты «Сетевые соединения» возможен выбор 
типа физического соединения «Мобильная связь», вызывающего вкладку «Настройка 
соединения мобильной связи» для конфигурирования интерфейса сотовой связи 
выбранного провайдера (рис. 40). 

Проверка и настройка базового уровня сетевой инфра- структуры. Команда 
пеізіаі отображает информацию о состоянии сетевого ПО, включая статистику 
сетевых интерфейсов и данные из таблицы маршрутизации. Наиболее 
востребованными её функциями являются: 

• вывод информации о конфигурации и статистике работы сетевых интерфейсов; 

• получение статических данных о сетевых протоколах; 

• проверка состояния сетевых соединений; 

просмотр таблицы маршрутизации. 












Управление безопасностью ОССН 


247 


Команда агр используется для просмотра, добавления и удаления записей в 
специальной системной таблице ядра ОССН — кэше АИР, в которой задано 
соответствие ІР- адресов хостов сети аппаратным интерфейсам сетевых адаптеров 
(НѴѴ-адресам). Для интерфейсов сети ЕІІіегпеІ в кэше АИР устанавливается 
соответствие между ІР-адресом хоста и МАС-адресом его сетевого адаптера. Для 
опроса хостов на предмет этой информации используется специальный протокол 
сетевого уровня АИР. Он передаёт широковещательные пакеты, которые не могут 
выйти за пределы локальной сети, то есть протокол АИР позволяет находить только 
адреса хостов, работающих в пределах одной сети (подсети). Рассылка пакетов 
протокола АИР происходит вскоре после начальной загрузки ОССН, поэтому протокол 
АИР практически не влияет на загруженность сети. 

Информацию о соответствии собственных ІР- адресов и НѴѴ-адресов сетевых 
интерфейсов ядро ОССН хоста сохраняет в таблице АИР и в файле /ргос/зеІРпеі/агр 
(рис. 41). 

В ОССН правила маршрутизации ІР- пакетов хранятся в системной таблице 
КегпеІ ІР гоиііпд ІаЫе ядра и в случае таблицы АИР отображаются в файле 
/ргос/зеІТ/пеІ/гоиіе (рис. 42). 

В ОС проекта ОЛ/Ш./шх применяются следующие виды маршрутизации: 

статическая — когда маршруты задаются явно и хранятся в таблице 
маршрутизации до момента необходимости их удале- ния; 

динамическая — выполняющаяся демонами гоиіесі или даіед, которые 
заполняют и модифицируют таблицу КегпеІ ІР гоиііпд ІаЫе на основе сообщений от 
других хостов сети (динамическая маршрутизация необходима в том случае, если 
структура сети не является статичной и меняется с течением времени, и в ней один и 
тот же компьютер может быть доступен по различным 
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Глава 3 


гооі8а5Ігв-*егѵ*г /ргос* гоиіе 
К«гпе! ІР гоиііпд ІдЫ* 

Оегііпвііоп Сліеиад Сеп*в$к 

ІѲ 8.8 Ѳ • 255 8 вв 

Ііпк-ІосвІ • 255 255 8 в 


Под* Меігіс Р*( Ц*е Ивее 
иве в вімв 
и 1888 8 8 <ИПѲ 


Рисунок 42. При мер таблицы Кете I ІР гоиііпд ІаЫе командой гоиіе 



Рисунок 43. Строка включения функции "ІР Іотагдіпд" для протокола ІРѵ4 

интерфейсам, например, через разные адаптеры ЕІІіегпеІ или беспроводный 
интерфейс). 

Команда гоиіе определяет только статические маршруты, записываемые в таблицу 
КегпеІ ІР гоиііпд ІаЫе. Пример вывода этой команды приведён на рис. 43. 

Поскольку в состав дистрибутива ОССН не включены демоны гоиіесі и даіесі, 
динамическая маршрутизация в ней не реализуется. 

В случае использования на хосте двух и более сетевых интерфейсов (например, 
когда хост применяется в качестве маршрутизатора или шлюза в другую подсеть) 
требуется указать ядру ОССН на необходимость включения функции «ІР Тогѵѵагсііпд», 
которая позволяет перенаправлять ІР-пакеты с одного сетевого интерфейса на 
другой. Это осуществляется путём вызова команды зузсіі. Для того чтобы функция 
«ІР Тогѵѵагсііпд» применялась каждый раз при загрузке/перезагрузке ОССН, 
необходимо задать соответствующий параметр в конфигурационном файле 
/еІс/зузсІІ.сопТ фис.44). 

З.б.З. Формирование корпоративного уровня сетевой инфраструктуры 
ОССН. Единое пространство пользователей 

В разд. 1.3.3 представлен вариант реализации корпоративной ЗЛВС для 
мультисервисной системы связи на базе ОССН. При этом рабочие станции 
пользователей ЗЛВС являются клиентами домен- 
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ной сетевой инфраструктуры, координируемой первичным контрол- лером домена 
(Ргітагу Оотаіп Сопігоііег — РОС) под управлением ОССН. Также было отмечено, 
что текущий релиз ОССН поддерживает как собственный вариант защищённой 
доменной сетевой инфраструктуры — Азіга Ипих Оігесіогу ('Л/.О), отличающейся от 
технологии Асііѵе Оігесіогу (АО) [95], которая базируется на службе Місгозоіі 
Оігесіогу Зегѵісе, так и вариант доменной сетевой инфраструктуры на базе проекта 
Р гееІРА, обеспечивающего совместимость с доменной инфраструктурой Асііѵе 
Оігесіогу. 

В основе указанных доменных сетевых инфраструктур лежат различные 
реализации следующих протоколов: 

• Орепі-ОАР — реализация протокола прикладного уровня /_ШР (Идіііѵѵеідііі 
Оігесіогу Ассезз Ргоіосоі) [56, 74] с открытым исходным кодом, обеспечивающего 
механизм «І&А» (ІбепШісаІіоп апб Аиіііепіісаііоп), а также поиск, добавление, 
изменение и удаление записей в единый каталог сетевых объектов; 

• ЗатЬа — реализация протокола прикладного уровня ЗМВ/ СІР8 (Зегѵег Меззаде 
ВІоск/ Соттоп Іпіегпеі Рііе Зузіет) [36, 72] с открытым исходным кодом, 
обеспечивающего удалённый доступ к сетевым ресурсам (файлам, принтерам), 
а также реализацию механизма ІРС (Іпіег-Ргосезз Соттипісаііоп) для 
удалённого выполнения приложений; 

• КегЬегоз — протокол взаимной аутентификации хостов передустановлением 
соединения между ними, реализующий механизм единого входа (Зіпдіе Зідп-Оп 
— 330) [77]. 

Благодаря поддержке указанных протоколов в рамках корпора- тивного уровня 
сетевой инфраструктуры ОССН зарегистрированные пользователи получают 
возможность: 

• централизованного хранения данных своих учётных записей и информации о их 
пользовательском окружении; 

• монтирования для учётных записей пользователей их домашних каталогов, 
расположенных на РОС, в состав локальной файловой системы хоста; 

• сквозной аутентификации на хостах, входящих с состав доменной сетевой 
инфраструктуры. 

Совокупность указанных возможностей обеспечивает формирование для 
пользователя хоста на основе ОССН, включённого в до- менную сетевую 
инфраструктуру, его ВПП. 

В общем виде схема организации ЕПП показана на рис. 45, при этом её 
логическими составляющими являются: 
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множество клиентов домена; 
контроллер (контроллеры) домена. 

В рамках клиента домена ЕПГІ реализует: 

локальное пространство имён — локальные базы данных учётных записей 
пользователей, имеющих возможность регистрации на клиенте домена; 

локальное пространство ресурсов — локальные файловые сущностии 
устройства, доступ к которым процессы от имени зарегистрированных учётных 
записей пользователей имеют в соответствии с политикой безопасности, 
определённой на клиенте домена. 

В рамках контроллера домена ЕПП реализует: 

глобальное пространство имён — базу данных учётных записей пользователей, 
имеющих возможность регистрации в доменной сетевой инфраструктуре; 

• глобальное пространство ресурсов — удалённые файловые сущности и устройства, 
располагаемые на контроллере домена и/или специально сконфигурированных клиентах 
домена — файловых серверах, доступ к которым процессы от имени зарегистрированных 
учётных записей пользователей имеют в соответствии с политикой безопасности, 
определённой в доменной сетевой инфраструктуре. 

Реализацию политики безопасности в рамках доменной сетевой инфраструктуры выполняет 
ЦВМ-модуль рагзес-сііз подсистемы безопасности РАН5ЕС, который инициализируется на 
контроллере и клиентах домена в процессе инсталляции на них ОССН с функционалом 
контроллера и клиента домена, соответственно. По своим функциональным возможностям 
модуль рагзес-сііз идентичен модулю рагзес, функционирующему в случае применения 
ОССН на компьютерах, не входящих в состав доменной сетевой инфраструктуры. 

Единое пространство имён доменной сетевой инфраструктуры формируется из 
локального и глобального пространств имён, расположенных соответственно на 
клиенте и контроллере домена. При этом в пределах единого пространства имён 
пользователь домена получает возможность как локальной регистрации на 
конкретном клиенте домена, так и централизованной регистрации на контроллере 
домена. В зависимости от вида регистрации процессы от имени учётной записи 
пользователя получают доступ к локальным ресурсам или ресурсам узлов домена в 
соответствии с локальной политикой безопасности или политикой безопасности 


домена. 
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В ОССН локальное и глобальное пространства имён (систем учётных записей 
пользователей и групп пользователей) функционируют параллельно. Для их 
различения выполнено разграничение диапазонов ІІЮ: значения ІІЮ меньшие 2500 
относятся к локальному пространству имён, а значения ІІЮ больше либо равные 2500 
— к глобальному пространству имён. 

Механизм «І&А» в пределах локального пространства имён на клиенте домена под 
управлением ОССН реализуется с использованием архитектуры РАМ, особенности 
использования которой рассмотрены в предыдущих параграфах главы. Реализация 
этого механизма в рамках глобального пространства имён в домене на базе ОССН 
основана на инфраструктуре /_ОЛР (хранение и администрирование учётных записей 
пользователей домена), функционирующей совместно с протоколом КегЬегоз. 

База данных учётных записей глобального пространства имён реализована в виде 
«Дерева директорий информации» ( Рігесіогу Іпіогтаііоп Тгее — РІТ). Подобная 
модель хранения данных основана на записях, содержащих наборы атрибутов, 
различающиеся по «Отличительному имени» ( ОізііпдиізІіесІ Мате — ОЛ/,), которые 
используются для обеспечения однозначности при обращении к записи. 

Каждый из атрибутов записи относится к конкретному типу и имеет одно или 
несколько значений. Типы обычно представлены строковыми переменными. 

О/Т глобального пространства имён контроллера домена на базе ОССН разделено на две 
ОМ-ветви: ои = Реоріе и ои = Огоир, которые свою очередь имеют дочерние ОЛ/-ветви, 
имеющие тип сп и содержащие атрибуты учётных записей самих пользователей домена, 
групп пользователей домена и их теневых паролей. В общем О/Т ресурсе контроллера 
домена указанные ЭЫ-ветви включены в О/Ѵ- ветви с/с = епдіпе и сіс = ІосаІ. В графическом 
виде общая структура О/Т контроллера домена на базе ОССН показано на рис. 46.С учётом 
МРОСП ДП-модели атрибуты О/Т-дерева дополняются ЭКІ-ветвями, определяющими 
информационные сервисы для мандатных уровней конфиденциальности и целостности. Эти 
дополнительные атрибуты находятся в файле /еіс/рагзес/тісіар.сопі ( рис. 47). 

В зависимости от необходимости использования локальной или глобальной реализации 
механизма «І&А» на клиенте домена производится их динамическое переключение, 
основанное на технологии /Ѵ55 (Мате Зегѵісе Зѵѵіісіі) [80]. Эта технология создаёт модульное 
окружение для управления пользовательскими учётными записями, 
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иШ — тоі 
шгі:\итЬег О 
%ШЫитЬег: О 
НотеШпсЮгу: /гоаі 
ІоуЗНеІІ: Ып/ЬаіН 


и Ш = ту^шег 
ииІ\:іп:Ы'г 1000 

/рОЫитЬег: 1000 
ІютеОігесІогу: /Ноте/тушег 
ІоцЗИеН: Ып/ЬазН 


ииі = оіНегиаег 
иШУитЫг: 1000 
уиІНитЬег: 1000 
НотеОіпхюгу: /Иоте/оіНегиіег 
Іо§5ЬеІІ: Ып/ЬаіЬ 


Рисунок 45. Структура ОП-дерева, реализующего глобальное пространство пользователей домена на базе ОССН 
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Рисунок 46. Дополнительные атрибуты ДІТ-дерева, определяющие информационные сервисы для реализации МРОСЛ 

ДП-модели 


реализованное в виде набора загружаемых библиотек (Ьаскепсіз). При этом базовые 
системные вызовы при применении технологии Л/55 реализованы в библиотеке дІіЬс, 
которая в зависимости от кон- фигурации Л/55 вызывает те или иные ЬаскепсІ (рис. 
48).Функции библиотеки едІіЬс, реализующие технологию Л/55 на 
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Рисунок 47.Схема реализации технологии N83 на клиенте домена под управлением ОССН 


клиенте домена под управлением ОССН, вызывают два Ьаскепд: 

НЬпзз_Ые — модуль, обеспечивающий идентификацию локальныхучётных 
записей пользователей и групп пользователей с использованием конфигурационных 
файлов /еіс/раззѵѵсі, /еіс/ дгоир, / еіс/ зііасіоѵѵ, / еіс/дзііасіоѵѵ (авторизация при этом 
выполняется соответствующим РЛМ-модулем); 

ІіЬпзз_ІсІар — модуль, обеспечивающий идентификацию учётных записей 
пользователей и групп пользователей домена с использованием соответствующих 
ОІЧ-ветвей О/Г-дерева на контроллере домена (авторизация при этом может 
выполняться как с использованием РАМ- модуля ІіЬрат ІсІар — связка N88/ РАМ, так 
и с использованием сквозной аутентификации по протоколу КегЬегоз — метод 
аутентификации по умолчанию). Конфигурация Л/55 задаётся в файле 
/еіс/пззѵѵіісіі.сопі. Таким образом, при выполнении процессов, требующих обращения 
к именованным сущностям, соответствующие вызовы функций библиотеки дІіЬс будут 
обращаться к функциям ЬаскепсІ, указанным в файле / еіс/пззѵѵіісіі.сопі. Пример 
файла /еіс/пззѵѵіісіі. сопі клиента домена на базе ОССН приведён на рис. 3.49. Кроме 
имён и идентификаторов учётных записей пользователей и групп пользователей 
технология /Ѵ55 позволяет определять имена и идентификаторы протоколов, номера 
портов сервисов, ЗР- адреса и имена хостов, а также другие данные. В частности, 
применительно к МРОСЛ ДП-модели технология Л/55 позволяет определять 
источники данных для задания мандатных уровней конфиденциальности и 
целостности, для этого используется конфигурационный файл еіс/рагзес/тзѵѵіісіі.сопі 
подсистемы безопасности РАР8ЕС (рис. 50). 
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Рисунок 48. Пример конфигурационного файла N55 на клиенте домена 
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Рисунок 49. Конфигурационный файл для определения источников данных на клиенте домена 


Для осуществления сквозной аутентификации пользователей домена на базе ОССН 
применяется протокол КегЬегоз. В рамках доменной инфраструктуры, основанной на 
применении ОрепЬОАР (представлена демоном зіарсі) и протокола КегЬегоз, 
механизм единого входа реализуется с использованием технологии ЗАЗЬ (Зітріе 
АиіЬепіісаііоп апЬ Зесигііу Ьауег) [81]. В частности, для версии МІТ КегЬегоз 5, 
используемой в ОССН, в рамках технологии ЗАЗІ- применён механизм ѲЗЗАРІ (ТЬе 
КегЬегоз Ѵегзіоп 5 Ѳепегіс Зесигііу Зегѵісе Арріісаііоп Ргодгат Іпіегіасе МесЬапізт) 
[42]. Таким образом, модель механизма единого входа в ОССН именуется ЬѲАРЬазесІ 
оп КегЬегоз (ЗАЗШЗЗАРІ). 

Конфигурационным файлом механизма ѲЗЗАРІ является файл / еіс/дззарі_тесЬ.сопі 
в котором определяется функция инициализации механизма при вызове библиотеки 
КегЬегоз 5 ѲЗЗАРІ (рис. 47). При этом общим конфигурационным файлом реализа- 
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Рисунок 50. Конфигурационный файл механизма КегЬегоз 5 (355АРI 


ции протокола МІТ КегЬегоз 5 является файл /е1с/кгсІ5.соп(, конфигурация КОС 
задаётся в файле ІеІс/кгЬ5ксІс/ксІс.сопі. 

Организация механизма «І&А» в пределах глобального пространства имён ЕГІГ1, 
реализуемого в ОССН, обеспечивает возможность пользователям доменной сетевой 
инфраструктуры на базе ОССН получать доступ к глобальному пространству ресурсов, 
поддержка которого возложена на модифицированную реализацию пакета программ ЗатЬа 
[57], именуемую как сетевая защищённая файловая система (СЗФС). СЗФС может 
функционировать как в составе контроллера домена (выполняющего при этом 
дополнительные функции файлсервера), так и в составе клиентов домена, реализующих 
функции файлсервера для предоставления доступа к собственным разделяемым ресурсам. 
Поскольку СЗФС является модификацией пакета программ ЗатЬа, она состоит из 
следующих компонент: 

серверного набора программ: демоны зтЬЬ и птЬЬ; 
клиентского приложения: зтЬсІіепІ ; 

набора утилит администрирования: іезфагат и зтЬзШиз', 
конфигурационных файлов: /еіс/затЬа/зтЬ.сопі и /еіс/зтЬ- пеііз. сопі. 

Дополнительно для администрирования СЗФС имеется графическая утилита «Общие папки 
(ЗатЬа)» (ІІу-асІтіп-затЬа), расположенная в меню «Настройки» главного пользовательского 
меню. 

Базовыми компонентами СЗФС являются демоны зтЬЬ и птЬсІ, а также клиентское 
приложение зтЬсІіепІ. Демон зтЬЬ реализует функции сервиса сетевой печати и разделения 
файлов для клиентских приложений зтЬсІіепІ, функционирующих в рамках доменной сетевой 
инфраструктуры на базе ОССН, а также клиентских прило- 
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жений, функционирующих под управлением ОС семейства МісгозоІІ ѴѴіпбоѵѵз. Конфигурация 
демона зтЬд в ОССН задаётся в файле I еіс/затЬа/зтЬ.сопі. Демон птЬд по умолчанию 
реализует функции сервиса имён протокола Л/еШ/05, а также может использоваться для 
запроса других сервисных служб имён. 

3.6.4. Служба АЬБ. Администрирование доменной 
сетевой инфраструктуры ОССН 

Рассмотренные компоненты доменной сетевой инфраструктуры ОССН требуют 
конфигурирования в процессе её установки на хос- ты, реализующие контроллеры и 
клиенты домена, а также адми- нистрирования в процессе эксплуатации домена. Для 
этого в ОССН имеется служба АІО, схема которой показана на рис. 3.52. 

Таким образом, служба АІО состоит из следующих компонент. Базовые компоненты, 
представленные пакетами программ конфигурирования: 
контроллера АІО; 
клиента АІО; 

хоста, выполняющего функции узла администрирования АІО (может 
располагаться на одном контроллере АІО или одном из клиентов АІО) - , 

клиента АІО, реализующего функции файл-сервера (может также 
располагаться на контроллере АІО). 

Так как ряд функций базовых компонентов являются обяза- тельными для различных 
ролей хостов домена АІО, указанные па- кеты собираются в кумулятивные пакеты. 
Например, кумулятивный пакет контроллера домена АІО — аід-зегѵег-дс содержит в 
своём составе пакеты клиента и администратора АІО. 

Расширения службы АШ, предназначенные для обеспечения большей функциональности 
базовых компонентов службы АІО за счёт подключения дополнительных функций, например, 
следующих: 

• организация и администрирование резервных контроллеров до- мена АІО и 
установление междоменных отношений доверия; 

• централизованное хранение настроек аудита и ОССН в целом; 

• конфигурирование подсистемы управления доступом к подклю- чаемым носителям. 
Наименование пакета расширения отражает его назначение, на- пример: 

• аіб-сііепі... — расширение клиентской части домена АІО - , 

• аіб-асітіп-... — расширение администрирования домена АІО; 
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Рис. 3.52. Схема службы АЬИ 
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• аід-зегѵег-... — расширение для организации хранения настроек на контроллере 
домена АІО. 

Администрирование домена АІО выполняется пользователями, обладающими 
соответствующими полномочиями. В зависимости от назначенных привилегий 
администраторов домена АІО можно раз- делить на следующие группы: 

• корневой администратор (имя адтіп/адтіп) — основной администратор 
домена АІО, обладающий всеми полномочиями по управлению доменом; 

• администраторы — пользователи с привилегией адтіп, обладающие 
полномочиями по управлению конфигурацией домена и учётными записями 
пользователей домена; 

• ограниченные администраторы — пользователи с привилегиями ііозіз-адд 
или аііііозіз-адд, обладающие полномочиями по добавлению хостов в состав 
домена; 

• пользователи утилит администрирования — пользователи с привилегией 
адт-изег, обладающие полномочиями по запуску утилит администрирования. 

Базовый администратор домена АІО, используя набор программ базовых 
компонентов службы АІО, а также их расширений и графическую утилиту 
«Управление политикой безопасности» (//у- адтіп-зтс) рабочего стола Пу, может 
выполнять следующие операции: 

• создание нового домена; 

• резервирование/восстановление конфигурации домена; 

• контроль целостности конфигурации домена; 

• добавление/удаление хостов в состав хостов домена; 

• управление учётными записями пользователей домена; 

• управление учётными записями сетевых служб домена; 

• управление параметрами ОССН, в первую очередь соответст- вующими 
МРОСЛ ДП-модели. 

В общем случае методику конфигурирования доменной сете- вой инфраструктуры на 
базе ОССН с использованием службы АІО можно разделить на следующие этапы. 

1. Настройка сетевого соединения на контроллере домена и хостах рабочих 
станций пользователей. 

2 . Настройка именования сервера и клиентов АІО. 

3. Конфигурирование и запуск сервера АІО на хосте, реализующем функции 
контроллера домена. 

4 . Запуск клиентов АІО на хостах рабочих станций. 
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Рисунок 52. Пример конфигурирования файла /еіс/іпозіз/ на хосте, реализующем функции контроллера домена 


На первом этапе учитывается, что способ сетевого соединения контроллера и 
клиентов домена АІО зависит от типа адресации, используемой в сетевом сегменте. 
Статическая адресация целесообразна при небольшом числе хостов, входящих в 
состав домена АІО. При этом сетевой интерфейс каждого хоста, входящего в домен 
Аі О, конфигурируется индивидуально. Динамическая адресация целесообразна при 
значительном числе хостов, входящих в состав домена АІО или их большой 
территориальной удалённости. 

В этом случае на контроллере АІО (или на другом специально выделенном хосте) 
конфигурируется и запускается сервер динамической сетевой адресации 0/-/СР 
(Оупатіс Нозі Сопіідигаііоп РгоіосоІ). 

На втором этапе для функционирования домена АІО обеспечивается настройка 
сетевых имён таким образом, чтобы сетевое имя хоста разрешалось, в первую 
очередь, как полное имя (например, азігазегѵег.ехатріе.ги). При этом команда 
ііозіпате должна возвращать короткое сетевое имя хоста (например, азіга-зегѵег) . 
При небольшом количестве хостов, входящих в домен АІО, такую настройку, как 
правило, выполняют вручную, конфигурируя файл /еіс/ііозіз (рис. 53). В случае 
большого количества хостов в составе домена АІО на контроллере домена (или на 
специально выделенном хосте) конфигурируют службу доменных имён ОМ 5 (Оотаіп 
Мате Зегѵісе). 

На третьем этапе конфигурируют серверную и клиентскую части домена АІО, 
реализованные в виде одного демона аШ: 

путём редактирования конфигурационного файла /еіс/аісі/ аІсІ.сопЦ рис. 54); 
запуская или повторно инициализируя демон аШ с помощью команд аід-іпіі (на 
контроллере АІО) и аісі-сііепі (на клиенте АІО) (рис. 55); 
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Рисунок 53. Пример конфигурирования файла /еіс/аід/аід.сопі на хосте, реализующем функци контроллера домена 
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каталоги) 
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Рисунок 54. Пример выполнения команды аід-іпі( с параметром соттН-сопПд на хосте, реализующем функции 

контроллера домена 

• конфигурируя параметры пароля базового администратора Л/.0 для реализации 
сквозной аутентификации на контроллере АІО (рис. 56). 

Эти действия осуществляются путём редактирования параметров файла 
/еіс/аісі/аід.сопі (при этом в большинстве случаев для всех этих параметров 
используются значения по умолчанию). 

Обязательной модификации подлежит параметр ЗЕЯѴЕЯ, в качестве значения 
которого указывается выбранное на втором этапе имя сервера(в примере на рис. 54 
это азіга-зегѵег.ехатріе.ги). 

На четвёртом этапе базовый администратор домена с использованием команды аісі- 
асітіп или графической утилиты «Доменная политика безопасности», расположенной 
в разделе «Сеть» меню «Панель управления» (рис. 57), создаёт или редактирует 
учётные записи пользователей домена, управляет компьютерами домена, а также 
политиками безопасности на активном сервере Л/.0. 
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Рисунок 55. Пример выполнения команды аід-іпіі с параметром іпіі на хосте, реализующем функции контроллера 

домена 


После настройки и запуска сервера /А/.0 и клиентов домена администратор Л/.0 может 
выполнять следующие функции: 

создание и/или администрирование учётных записей пользователей /А/.0; 
создание и/или администрирование групп пользователей /А/.0; 
добавление и удаление хостов рабочих станций в/из состава домена; 
резервирование/восстановление учётной информации баз данных домена; 
конфигурирование привилегий и параметров безопасности ОССН для учётных 
записей пользователей и групп пользователей домена; 
конфигурирование политик паролей КегЬегоз ; 
администрирование доступа к съёмным устройствам; 
администрирование учётных записей сетевых служб (сервисов) домена; 
контроль целостности (аудит) конфигурации домена. 
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Рисунок 56.Интерфейс конфигурирования сервера АІР для домена "ехатріе.ги" 


В условиях необходимости интеграции клиентов и сервисов доменной сетевой 
инфраструктуры ОССН с доменной инфраструктурой, основанной на технологии 
Асііѵе Оігесіогу, сформированное в рамках технологии РгееІРА пространство 
пользователей расширяется за счет доступа к объектами и сервисам доменной 
инфраструктуры основанной на технологии Асііѵе Оігесіогу, включая возможности 
доверительных отношений АО Тгизіз [96]. 

3.6.5. Служба РгееІРА. Формирование гетерогенной доменной сетевой 

инфраструктуры 

В общем случае решение на основе доменной сетевой инфраструктуры /появляется 
эффективным в рамках инфокоммуникационных систем, узлы которых целиком 
базируются на ОССН. К таким системам, в частности, следует относить различного 
типа ЗЛВС, а также АСЗИ, ориентированные на обработку информации с различным 
уровнем конфиденциальности. 

Между тем существует широкий сегмент инфокоммуникационных систем, в которых 
доля узлов, базирующихся на решениях ОС семейства Місгозоіі ѴѴіпдоѵѵз, является 
достаточно высокой. В таком сегменте в качестве способа централизованного 
управления идентификационными и аутентификационными данными пользователей, 
а также учёта доступных сетевых ресурсов, таких как общие 
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палки и принтеры, используются архитектурные решения Місгозоіі Асііѵе Оігесіогу 
(АО). В силу того, что инфраструктура АО является стандартом де-факто доменной 
сетевой инфраструктуры, со- здание гетерогенных инфокоммуникационных систем с 
узлами на основе ОС семейства Місгозоіі ѴѴіпсІоѵѵз и ОССН является весьма 
проблематичным. В первую очередь из-за необходимости поиска приемлемого 
решения для интеграции сетевых ресурсов ОССН, а также авторизованных в ней 
пользователей в доменную сетевую инфраструктуру АО. 

Основной проблемой такой интеграции является необходимость решения задачи 
поддержки кроссдоменных доверительных отношений АО — Асііѵе Оігесіогу Тгизіз. 

В общем виде доверительные отношения Асііѵе Оігесіогу Оотаіп Зегѵісе (АО ОЗ) 
являются защищённым каналом связи для проведения аутентификации между такими 
объектами, как домены АО ОЗ, лес доменов (Оотаіп Тогезі) и инфраструктуры Г/Л//Х 
Неаітз, реализованной на базе ИеаітсІ (Неаіт Оізсоѵету) [45] — О-Виз сервиса, 
позволяющего выполнять настройку аутентификации и членства в домене. В целом, 
наличие доверительных отношений позволяет организовать междоменный доступ к 
ресурсам, пользователям, группам и узлам инфокоммуникационных систем. 

Виды доверительных отношений Асііѵе Оігесіогу Тгизіз представлены на рис. 46. 



Рисунок 57.Виды доверительных отношений АО Тгизіз 
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Таким образом, в рамках инфраструктуры АО 08 внутрифирменные доверительные 
отношения являются двухсторонними отношениями типа «родитель-потомок». Кроме того, 
домены в рамках одного леса могут устанавливать односторонние доверительные 
отношения типа «Ярлык» ( ЗМогісиі Тгизіз). 

Кроссдоменные доверительные отношения ( Сгозз-Оотаіп Тгизіз) относятся к следующим 
типам: 

двухсторонние доверительные отношения между лесами доменов АО] 

односторонние доверительные отношения, которые домен АО (на рис. 46 — домен АО 
из леса Рогезі 3) может установить с произвольным доменом, не относящимся к 
собственному лесу; 

внешнее одностороннее доверительное отношение, которое домен АО, созданный на 
базе ОС ѴѴІпсіоѵѵз 4.0 (устаревшее технологическое решение), может установить с 
произвольным доменом АО произвольного леса доменов; 

внешнее одностороннее отношение Неаіт, которое лес доменов АО (на рис. 46 — лес 
Рогезі 2) может установить с доменом на базе инфраструктуры ^NIX Неаітз. 

В общем случае доверительные отношения появляются двухэтапным процессом. На первом 
этапе происходит установление од- ного из перечисленных выше типов доверительных 
отношений. На втором этапе, в рамках установленного типа доверительных отно- шения 
выполняется предоставление соответствующих разрешений на доступ к ресурсам АО. 

Если между доменами АО 1 и 2 установлены доверительные отношения, то пользователи 
домена 1 могут аутентифицироваться на контроллере домена 2 с использованием 
специальной учётной записи, расположенной на контроллере домена 2. Двунаправленность 
таких отношений означает, что на контроллере домена 1 поддерживаются специальные 
учётные записи пользователей домена 2. Такие специальные учётные записи создаются с 
использованием вызовов протокола МЗ-НРС. 

В рамках решения задачи предоставления разрешений на доступ к ресурсам для 
установленных доверительных отношений меж- ду доменами или лесами доменов АО 
действует принцип тран-зитивности, согласно которому, если доверительные отношения 
установлены между доменом 1 и доменом 2, а также между доменом 2 и доменом 3, то 
считается, что между доменами 1 и 3 также установлены доверительные отношения. 
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Такие возможности достигаются за счёт того, что пользователи и группы 
пользователей инфраструктуры АО ОЗ идентифицируются едиными 
идентификаторами безопасности (Зесиге Ю — ЗЮ), являющимися уникальными для 
каждого домена АО. Идентификаторы ЗЮ используются для управления доступом к 
ресурсам домена АО в рамках сеансов протокола ЗМВ. Проверка ЗЮ позволяет 
получить доступ к списку АСЬ, связанному с запрашиваемым ресурсом или ЛРІ- 
функциями запрашиваемого сетевого сервиса. Организация доверительных 
отношений между двумя доменами АО фактически означает делегирование функции 
преобразования имени пользователя в его ЗЮ и наоборот контроллеру домена АО, 
который владеет сетевым ресурсом, к которому пользователь осуществляет доступ. 
Такое единообразное управление доступом на основе единого пространства 
идентификаторов ЗЮ позволяет любой протокол аутентификации, например, 
аутентификация с использованием серве- ра /_ШР или аутентификация КегЬегоз. В 
этом случае важным является, чтобы в рамках этих протоколов реализовывался поиск 
требуемого идентификатора ЗЮ. 

Как было рассмотрено в разд. 1.3, в целях интеграции сетевых ресурсов ОССН, а также 
организации членства пользователей, авторизованных в ОССН, в доменной сетевой 
инфраструктуре АО ОЗ, в релизе 1.6 ОССН реализована поддержка доменной 
инфраструктуры РгееІРА. Эта инфраструктура разрабатывалась для организации поддержки 
членства клиентских узлов на базе ОС семейства МісгозоП ѴѴІпсІоѵѵз в домене ІРА. Начиная с 
версии 3.0 (ІРАѵЗ), доменная инфраструктура РгееІРА поддерживает кроссдоменные 
доверительные отношения Сгозз-Оотаіп Тгизіз. 

Такая поддержка является возможной, поскольку инфраструктуры АО ОЗ и РгееІРА 
можно рассматривать как КегЬегоз Пеаітз. Это означает, что в домене АО можно настроить 
кроссдоменные доверительные отношения для МІТ КегЬегоз Реаіт, а именно КегЬегоз 5, 
являющейся основой сервиса аутентификации РгееІРА. 

Поскольку при организации кроссдоменных доверительных отношений между 
доменами АО ОЗ и МІТ КегЬегоз Реаіт фактически отсутствует контроллер домена АО в МІТ 
КегЬегоз реализован механизм управления идентификаторами ЗЮ на основе их 
сопоставления с локальными учётными записями пользователей. 

В рамках сеанса ЗМВ, поддерживаемого инфраструктурой АО ОЗ, пространство имён 
специальных учётных записей для реализации доверительных отношений является 
совместимым как с серви- 
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Обертка КегЬегоз АиОіогігаііоп Баіа: тип АО-\ѴШ2К-РАС 



Рисунок 58.Формат упаковки структуры М5-РАС в формат КегЬегоз Тіскеі 

сом идентификации контроллеров АО, так и с сервисом КегЬегоз КОС. 

Совместимость достигается за счёт того, что имена пользователей МІТ КегЬегоз 
Реаіт дополняются именем домена ОЛ/5. То есть, контроллер АО домена /401 будет 
именовать себя для контрол- лера МІТ КегЬегоз А02 как /40/$©Л02.00М4/Л/, а 
контроллер МІТ КегЬегоз А02 будет сопоставлять это имя с локальной учётной 
записью /407. 

Протокольный блок данных авторизации М8-РАС, используемый в инфраструктуре 
/40 05 для поддержки пространства имён специальных учётных записей, в случае 
взаимодействия с МІТ КегЬегоз Реаіт использует специальные обёртки, для упаковки 
его в формат билета КегЬегоз (КегЬегоз Тіскеі). Формат такой упаковки представлен 
на рис. 3.59. 

В обобщённом виде возможности интеграции доменной инфраструктуры 
РгееІРА и инфраструктуры на базе /40 05 представлены на рис. 3.60. 

Таким образом, основой доменной инфраструктуры ІРА, как и в случае доменной 
сетевой инфраструктуры АЬО, является ЗатЬа — пакет программ 
кроссплатформенной поддержки доступа к сетевым ресурсам с использованием 
протокола 5МВ/СІРЗ. При этом, начиная с версии ЗатЬа 4, в них была добавлена 
роль контроллера домена ЗатЬа Оотаіп СопІгоІІег (ЗатЬа ОС), реализующая 
частичную функциональность сервиса АО 03, а именно: 
сервис аутентификации на базе КегЬегоз 5; 

сервис каталогов, поддерживающий совместимость с протоколом /_ШР и 
модель репликации Асііѵе Оігесіогу Реріісаііоп МосІеІ, 

сервис управления групповыми политиками на основе объектов групповой 
политики ( Огоир Роіісу ОЬіесІ — ОРО; 

ОЛ/5-сервер на основе реализации Б/Л/О. 
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Рисунок 59. Структура интеграции доменных сетевых инфраструктур АО 05 и ІРА 


Возможности контроллера ЗатЬа ОС дополняются компонентами ІРА, 
обеспечивающими поддержку отношений Сгозз-Оотаіп Тгизіз. На рис.61 
представлена структура контроллера домена ІРА (ядра РгееІРА) и связи между её 
элементами. 

Таким образом, базовыми компонентами РгееІРА являются: 

1. Демон етрсі ( ЕпсІ Роіпі Маррег — ЕРМ) — сервис прямого подключения узлов 
на базе ОС семейства Місгозоіі ѴѴіпсІоѵѵз к службам М8-РРС. 

2 . Сервисы МеІІодоп, /_5Л и ЗАМР, обеспечивающие в совокупности организацию 
контроллеру домена инфраструктуры АО 05 доверительных отношений с 
контроллером домена ІРА. Они также реализуют управление данными специальных 
учётных записей пользователей в каталоге /_0/\Р, в частности следующие функции; 

МеІІодоп — сервис организации защищённого канала кроссдоменного 
взаимодействия для выполнения сквозной аутентификации как на этапе создания 
доверительных отношений, так и на этапе кроссдоменного взаимодействия; 

подсистема локальной авторизации /_5А (/.оса/ Зесигііу Аиігіогііу) — реализует 
алгоритмы служб перевода имён пате2зісІ и зісІ2пате, реализующих трансляцию 
идентификаторов ЗЮ и локальных имён МІТ КегЬегоз Реаіпг, 

сервис ЗАМР (Зесигііу Ассоипі Мападег Ретоіе), используемый для удалённого 
управления специальными учётными записями попротоколу МЗ-РРС ; 


















Управление безопасностью ОССН 


269 


\ Администратор 



Рисунок 60. Структура ядра РгееІРА 


библиотека ІіЬпсІг_кгЬ5 реализует алгоритмы упаковки и распаковка структур 
авторизации, в частности структуры М8-РАС, в билетах КегЬегоз Тіскеіз. 
Администратор домена ІРА выполняет управление ядром РгееІРА с использованием 
ѴѴеЬ-интерфейса, разворачиваемого на базе штатного ѴѴеЬ-сервера, например 
арасЬе 

На рис. 62 и 63 представлены этапы работы перечисленных компонентов ядра 
РгееІРА при организации доступа клиента домена АО к ресурсам сервиса, 
зарегистрированным в домене ІРА, и клиента домена РгееІРА к ресурсам, 
зарегистрированным в домене АО (предполагается, что кроссдоменные 
доверительные отношения уже установлены). 

Поскольку в рамках доменных инфраструктур ОССН АІО и РгееІРА сквозная 
аутентификация реализуется сервисом КегЬегоз КОС, то политика безопасности 
организуемая І_ЗМ-модулем рагзес- сі!з в рамках доменной инфраструктуры АЮ 
распространяется и на доменную инфраструктуру РгееІРА, что позволяет 
организовать 
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Рисунок 61.Этапы процесса кроссдоменного доступа клиента домена АО к ресурсам сервиса домена ІРА 
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Рисунок 62. Этапы процесса кроссдоменного доступа клиента домена ІРА к ресурсам сервиса домена АЭ 


масштабируемую гетерогенную доменную инфраструктуру АО РгееІРА, 
поддерживающую единую политику безопасности, как на этапе миграции — 
поэтапного перехода от доменной инфраструктуры АО к инфраструктуре РгееІРА, так 
и на этапе эксплуатации инфокоммуникационных систем, требующих поддержки 
гетерогенности платформ ОС семейства МісгозоП ѴѴіпсІоѵѵз и ОССН. 
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3.7. Дополнительные функции безопасности 


Помимо основных уже рассмотренных функций безопаснасности ОССН 
содержит ряд дополнительных функций, позволяющих обеспечить защиту от 
определённых частных угроз, которые в совокупности, основываясь в первую очередь 
на реализованном в ОССН, начиная с версии 1.6, полнофункциональном мандатном 
контроле целостности, существенно повышают общую защищенность ОССН 
Активизация этих функций, как правило, начинается уже при установке ОССН, для 
чего используется интерфейс, представленный на рис. 64. Детали применения и 
настройки этих функций отражены в разделе справочного центра ОССН Азіга Ипих 
Неб* Воок [102]. Перечислим и кратко охарактеризуем эти функции. 

Замкнутая программная среда. Замкнутая программная среда представляет 
собой расширение подсистемы управления доступом, призванное затруднить 
функционирование в защищаемой ОССН вредоносного ПО. В общем случае система 
правил замкнутой программной среды сводится к двум основным требованиям: 


• разрешать запуск только тех приложений, которым это явно 
разрешеноспециально уполномоченным субъектом доступа, при этом 
непривилегированные субъекты доступа не имеют полномочий корректировать 
перечень разрешённых приложений; 
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Рисунок 63. Интерфейс активизации дополнительных функций защиты при установке ОССН 
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• ограничивать доступ субъектов к сущностям, учитывая, в том числе 
посредством какого приложения осуществляется доступ. Первое из перечисленных 
требований реализовано в ОССН спомощью цифровой подписи, которой снабжены 
все исполняемые файлы, входящие в дистрибутив ОССН. 

Поддерживаются три варианта реакции ядра ОССН на попытку загрузки для 
выполнения исполняемого файла, не имеющего корректной цифровой подписи: 

• загрузка запрещается (штатный режим); 

• загрузка разрешается, генерируется сообщение аудита (режим отладки политики 
безопасности); 

• загрузка разрешается (режим разработчика ПО, не должен применяться в случае 
реальной эксплуатации ОССН). 

Настройка механизма автоматического контроля целостности файлов осуществляется путём 
редактирования конфигурационного файла / е іс/сіідзід/сіідзід_іпіігатіз.соп 1. Для установки 
режима разработчика следует вставить в этот файл строку: 0І05І0_І-0А0_КЕѴ5= О 
Для установки режима отладки политики безопасности: ОЮ5Ю_ШАО_КЕУ5= 1 
Для установки штатного режима: 

0Ю5Ю_ША0_КЕУ5= 1 ОІв8Ів_ЕМЕОНСЕ= 1 

Ключи цифровой подписи загружаются в каталог /еіс/сіідзід/ кеуз. 

Помимо исполняемых файлов, контроль целостности может также устанавливаться и на 
файлы данных. В этом случае целостность данных проверяется при каждом открытии 
поставленного на контроль файла. Для включения этой возможности следует вставить в 
файл /еІс/сІідзід/сІідзід_іпіІгатІз.сопІ строку: 

ОЮ5КЗ_ І!5Е_ХА ТТН= 1 

Шаблоны имён поставленных на контроль файлов перечисляются в файле 
ІеІс/сІідзід/хаШ_сопІгоІ. Ключи, используемые для проверки цифровых подписей 
поставленных на контроль файлов, хранятся в каталоге /е1с/сИдзід/хаПг_кеуз. Текущее 
состояние системы контроля целостности хранится в файле Іеіс/сіідзід/епіогсе. 

Кроме того, проверку цифровых подписей можно выполнять с помощью утилит командной 
строки дозізит и дозІзит_ігот.сІеЬ. 

Реализован механизм, обеспечивающий автоматическую проверку цифровых 
подписей всех загружаемых для выполнения исполняемых файлов. Фактически данный 
механизм реализует частный случай первого правила изолированной программной среды, 
при 



274 


Глава 3 



Рисунок 64. Управление параметрами замкнутой прогаммной среды 


этом множество разрешённых для выполнения приложений определено как 
множество приложений, файлы которых имеют корректную цифровую подпись их 
доверенного разработчика. 

Управление всеми вышеперечисленными параметрами удобнее всего осуществлять 
с помощью раздела «Замкнутая программная среда» графической утилиты ІІу-адтіп- 
зтс, представленного на рис.65. 

Для проверки цифровой подписи конкретного файла в ручном режиме можно 
воспользоваться вкладкой «Подпись» окна «Свойства файла» утилиты «Менеджер 
файлов», как показано на рис. 3.60, 

Запрет установки бита исполнения и блокировка интер- претаторов. Обычно в ОС 
семейства Ипих процесс-владелец файла имеет полный, ничем не ограниченный 
доступ к атрибутам защиты этого файла. Любой пользователь может присвоить 
любому своему файлу любые атрибуты защиты. В частности, процесс-владелец 
файла может произвольно манипулировать правом доступа на вы- полнение (X) к 
файлу, что интерпретируется в ОС семейства Ипих как признак исполняемости 
файла. Это позволяет ему устанавливать в домашнем каталоге учётной записи 
пользователя, от имени которой он функционирует, произвольные приложения, 
создавать и редактировать скрипты командного интерпретатора Ьазіі и других 
интерпретируемых языков программирования. Данная возможность значительно 
упрощает внедрение и функционирование в ОС вредоносных программ. 

Фактически единственный способ ограничить возможности вносить сторонние 
приложения в ОС семейства Ипих — разместить домашний каталог учётной записи 
пользователя на отдельном разделе, смонтированном с параметром поехес. 
Практическое применение 
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Рисунок 65.Проверка цифровой подписи фалйа 


данного способа сопряжено со множеством неудобств, администраторы ОС 
практически никогда так не делают. 

В ОССН, начиная с версии 1.6, поддерживается возможность запретить создание 
исполняемых файлов процессам непривилегированных учётных записей 
пользователей, соответственно имеющих уровень целостности «Низкий» (0). В этом 
случае учётная запись пользователя, процессы которой способны устанавливать 
младшие биты в байтах векторов доступа к файлам, должна обладать уровнем 
целостности «Высокий» (63). 

Запрет установки бита исполнения может быть дополнен блокировкой 
интерпретаторов. Если данная функция безопасности включена, то от имени учётных 
записей пользователей, не входящих в группу азіга-сопзоіе, запрещено стартовать 
процессы интерпрета- 
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торов скриптовых языков программирования: Ьазіі, регі, руМоп, гиЬу\л т. п. Блокировка 
интерпретаторов реализована на основе эвристических правил и не является 
абсолютно надёжной, однако онасущественно затрудняет непривилегированному 
процессу несанкционированное применение средств программирования на 
интерпретируемых языках. 

Запрет исполнения данных. Одним из наиболее распространённых и опасных 
типов уязвимостей ПО является переполнения буферов [58]. Уязвимости данного, 
типа позволяют нарушителям вносить в ОС вредоносные приложения под видом 
наборов данных — документов, изображений, сетевых пакетов и т. д. В результате 
эксплуатации переполнения буфера уязвимое приложение ошибочно интерпретирует 
часть предоставленных ему данных как программный код, который немедленно 
исполняется. При определённом стечении обстоятельств эксплуатация переполнения 
буфера может позволить нарушителю захватить полный контроль над атакуемой ОС. 
В состав ОССН включены защитные механизмы, специально предназначенные для 
того чтобы затруднить нарушителю эксплуатацию переполнений буфера. Одним из 
таких механизмов является запрет исполнения данных. 

При включении данного механизма все области оперативной памяти, 
содержащие все данные всех приложений, помечаются как запрещённые для 
исполнения программного кода. Такое исполнение разрешается только в тех областях 
памяти, которые представляют собой проекции секций кода исполняемых файлов, 
загруженных для выполнения штатным порядком функционирования ОССН. В 
результате эксплуатация переполнений буферов становится возможна только с 
применением специальных технологий обхода данной защиты {НОР, ЛОР и т. д.), что 
серьёзно затрудняет создание эксплойтов для ОССН. 

Не все компиляторы совместимы с запретом исполнения данных. Некоторые 
компиляторы в результате оптимизации програм- много кода или по другим причинам 
создают приложения, пред- полагающие исполнение программного кода в куче или 
даже стеке. Иногда, например, компиляторы для ускорения работы приложения 
преобразуют таблицу указателей на программный код в таблицу команд безусловного 
перехода на соответствующие адреса, что делает полученное приложение 
несовместимым с запретом исполнения данных. 

Все приложения, входящие в состав дистрибутива ОССН или 
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включённые в официальный репозиторий, совместимы с запретом исполнения 
данных. Единственная причина, которая может потребовать отключить запрет 
исполнения данных, актуальна когда есть необходимость обеспечить корректную 
работу в ОССН сторонних приложений, несовместимых с запретом исполнения 
данных. Такое отключение существенно снижает защищенность ОССН, и его следует 
избегать. 

Ручное управление параметрами политики запрета исполнения данных можно 
осуществлять посредством утилиты командной строки рахсіі. 

Очистка освобождаемых областей на жёстком диске. Обычно в ОС семейства 
Ипих освобождаемые области на жёстком диске освобождаются только логически, без 
затирания содержащей- ся в них данных. Если в них содержались конфиденциальные 
дан- ные, то после перезагрузки ОС они потенциально могут стать доступны 
нарушителю. На практике задача выявления конфиденциальных данных в свободных 
областях жёсткого диска решается не так просто, как может показаться, — искомые 
данные присутствуют там в виде множества коротких отрезков, собрать из которых 
полный набор данных крайне затруднительно. Тем не менее для противодействия 
этой угрозе в ОССН поддерживается функция очистки освобождаемых областей 
жёсткого диска, при её включении все освобождаемые области затираются 
немедленно после освобождения. 

Как и подавляющее большинство других современных ОС, ОССН реализует 
концепцию виртуальной памяти, когда редко используемые страницы оперативной 
памяти временно вытесняются на жёсткий диск. Виртуальная память позволяет в 
несколько раз увеличить объем доступной приложениям памяти ценой незначи¬ 
тельного снижения производительности ОС. Подобно другим освобождаемым 
областям жёсткого диска, данные страничного обмена (т. е. фрагменты оперативной 
памяти, временно вытесненные на жёсткий диск) могут содержать конфиденциальные 
данные, которые потенциально могут стать доступными нарушителю. В ОССН 
поддерживается функция очистки разделов страничного обмена, она может 
включаться независимо от функции освобождения других областей жёсткого диска. 
Включение упомянутых функций незначительно замедляет работу ОССН. 

Контроль целостности (неизменности) файлов. Администратор ОССН может в 
любой момент проверить совпадение ис- 
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Рисунок 66. Интерфейс утилиты проверки целостности (неизменности) файлов 


полняемых файлов ОССН с соответствующими файлами дистрибутива. Для проверки 
целостности (неизменности) используется графическая утилита ІІу-асІтт-іпІ-сІіеск, 
интерфейс которой представлен на рис. 3.67. 

Элементы интерфейса имеют следующее назначение: 

Точка монтирования носителя — полный путь к носителю с дистрибутивом 
ОССН. 

Монтировать — указывает, должен ли носитель быть смонтирован 
автоматически. 

Фильтры / Принудительно — перечень файлов и каталогов, целостность 
которых проверяется в любом случае, даже если они также содержатся в перечне 
«Игнорировать». 
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Фильтры / Игнорировать — перечень файлов и каталогов, целостность 
которых не проверяется, кроме случаев, когда они также присутствуют в перечне 
«Принудительно». 

Отчёты — пути к файлам, в которые будут помещены отчёты о проверке 
целостности в форматах соответственно, текстовом, НТМІі или АМ_. 

Не выводить дополнительных запросов — блокирует выдачу утилитой 
дополнительных сообщений наподобие «Вставьте диск». 

Начать проверку — начать проверку немедленно. 

Целостность файлов, не включённых ни в список «Принудительно», ни в список 
«Игнорировать», по умолчанию проверяется. 

Поддерживается возможность выполнять периодический регламентный контроль 
целостности, что обеспечивается специальным набором приложений, запускаемых 
посредством системного планировщика сгоп. Для управления данным механизмом 
служит утилита командной строки аііск, а также конфигурационный файл ІеісІ 
аііск.сопі. 

Рекомендуется, как минимум, ежедневно проверять целостность следующих файлов: 
ядро /Ьооі/ѵіпііпиг-*; 
модули ядра /ІіЬ/тосІиІез/*; 

модули подсистемы аутентификации /ІіЬ/зесигііу/рат; 
образы временной файловой системы /Ьооі/іпіігсі.ітд-*; 
конфигурация загрузчика ІЬооІ/дгиЬ/тепи.Ізі; 
конфигурация ядра Іеіс/зузсІІ.сопІ ; 
конфигурация процесса іпіі/еіс/іпіПаЬ; 

конфигурация графической подсистемы Іеіс/Х1 1 / деіаиіі- сііз- ріаутападег; 

конфигурация подсистемы аутентификации /еіс/рат.*; 

конфигурация ЫР5 /еіс/ехрогіз; 

порядок монтирования файловых систем /еіс/ШаЬ; 

скрипты автозапуска демонов Іеіс/іпН.сІ/* и ссылки на них /еіс/гс*; 

список учётных записей пользователей /еіс/раззѵѵсі; 

список групп учётных записей пользователей /еіс/дгоир; 

список безопасных терминалов Іеіс/зесигеііу; 

список зарегистрированных командных интерпретаторов / еіс/ зкеііз; 
исполняемые файлы из каталогов /Ып/*, /зЫп/*, /изг/ЫпГ, /изг/зЫп/*. 
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Управление доступом к подключаемым устройствам. Практически у всех 
организаций, предъявляющих повышенные требования к безопасности информации, 
в состав этих требований входит обеспечение управления доступом к подключаемым 
устройствам, в первую очередь, ІІЗВ-дискам. Известно множество случаев, когда 
бесконтрольное использование подключаемых устройств приводило к внедрению в 
защищаемые системы вредоносного ПО. 

В ОССН поддерживается возможность запрещать подключение 
незарегистрированных устройств, а зарегистрированным устройствам назначать 
мандатные метки конфиденциальности и целостности, а также ограничивать 
дискреционные права доступа к хранящимся на них файлам и каталогам. Управление 
политикой ограничения доступа к подключаемым устройствам реализуется путём 
редактирования конфигурационного файла /еіс/рагзес/ деѵісез.сід либо средствами 
АІО. В качестве клиентской программы удобнее всего использовать раздел 
«Устройства и правила» графической утилиты ііуасітіп-зтс. 



Контрольные вопросы 

• Как мандатное управление доступом позволяет повысить защищенность 
ОССН? 

• В каких файлах ОССН хранятся поддерживаемые в её конкретном эземпляре 
мандатные уровни конфиденциальности и неиерархические категории? 

• Каким образом в ОССН по умолчанию назначаются мандатные атрибуты 
файлам и каталогам? 

• Какая утилита используется в ОССН для управления политикой без- опасности? 

• Как пользователю проще всего узнать мандатные атрибуты текущего сеанса 
работы с ОССН? 

• Как пользователю проще всего узнать мандатные атрибуты файла или 
каталога? 

• Как можно запустить приложение с мандатными атрибутами, отличными от 
мандатных атрибутов текущего сеанса работы пользователя с ОССН? 

• Для чего предназначен мандатный контроль целостности? 

• Как проще всего узнать уровень целостности текущего сеанса работы 
пользователя? 

• Какие дополнительные меры применяются в ОССН для усиления защиты 
графической подсистемы? 

• Какие настройки подсистемы аутентификации поддерживает ОССН? 

• Как можно просмотреть журналы аудита ОССН? 

• Как осуществляется управление политикой аудита ОССН? 

• В чём разница в реализации функций управления доступом /_$Л//-модулей рагзес 
и рагзес-зііз ? 

• Для какой версии протокола ІР подсистема безопасности ОССН РАН- 8ЕС 
обеспечивает раздельную реализацию управления доступом? 
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• Поддерживает ли ядро ОССН протоколы динамической маршрутизации? 

• В какой подкаталог файловой системы /ргос отображается таблица КегпеІ ІР 
гоиііпд ІаЫе ядра ОССН? 

• Является ли доменная сетевая инфраструктура ОССН совместимой с 
инфраструктурой Місгозоіі Асііѵе Оігесіогу Зегѵісе? 

• Какой протокол используется в сетевой инфраструктуре ОССН для реализации 
механизма единого входа (550)? 

• Из каких логических компонентов состоит ВПП ОССН? 

• Каковы особенности модификации дерева директорий информации (ОІТ- 
дерева) базы данных учётных записей пользователей глобального пространства имён 
применительно к реализации МРОСЛ ДП-модели? 

• С использованием какой технологии происходит динамическое пере- ключение 
имён в рамках ЕПП ОССН? 

• Какой механизм является основой модульной реализации метода единого входа 
(550) доменной сетевой инфраструктуры ОССН? 

• Какие сервисы (демоны) являются базовыми компонентами СЗФС ОССН? 

• Какие пакеты механизма /4/.0 в ОССН являются базовыми, а какие реализуют 
расширенные функции? 

• Какие типы доверительных отношений доменной сетевой инфраструктуры 
Асііѵе 

• Оігесіогу Оотаіп Зегѵісе являются внутридоменными, междоменными и 
кроссдоменными? 

• Какая идентификационная информация о пользователе/группе пользователей 
домена Асііѵе Оігесіогу используется для реализации управления доступом к 
ресурсам домена и организации междоменных доверительных отношений? 

• На основе какого технологического решения инфраструктура ГгееІРА позволяет 
организовать кроссдоменные доверительные отношения с инфра- структурой Асііѵе 
Оігесіогу Оотаіп Зегѵісе ? 

• Какой протокольный блок данных инфраструктуры Асііѵе Оігесіогу Оотаіп 
Зегѵісе упаковывается в билет КегЬегоз Тіскеі в процессе авторизации пользователя 
при кроссдоменных доверительных отношениях? 

• Какая версия пакета программ ЗатЬа используется в инфраструктуре РгееІРА ? 



• Какая служба в составе инфраструктуры РгееІРА реализует перевод имён 
пользователей в их идентификаторы безопасности (5/0) и обратно? 

• Какую функцию в составе инфраструктуры РгееІРА реализует библиотека 
ІіЬпсІг_кгЬ5? 

• Какой протокол использует инфраструктура РгееІРА для организации 
удалённого управления кроссдоменными (специальными) учётными записями 
пользователей и групп? 

• Какие дополнительные функции безопасности реализованы в ОССН на основе 
Азіга Ипих Ред-Воок и как они администрируются? 



4. 1. Лабораторная работа № 1 
Работа с учётными записями пользователей и группами 

Цель работы 

Изучить особенности администрирования локальных учётных записей пользователей и групп 
в ОССН с использованием командной строки и графического интерфейса. 

Время выполнения работы 4 академических часа. 

Краткие теоретические сведения 

ОССН — многопользовательская ОС, потому учётная запись пользователя — 
ключевой элемент всей системы управления доступом. Для идентификации учётных записей 
пользователей и групп в ОССН как во всех ОС семейства Плох используются иісі и дісі 
соответственно (подробно порядок работы в ОССН с этими идентификаторами рассмотрен в 
главе 1). Каждая учётная запись пользователя должна принадлежать как минимум одной 
группе — первичной группе. При создании учётной записи пользователя командой асісіизег 
или с использованием графической утилиты Пу-адтіп-зтс создаётся группа, имя которой 
совпадает с системным именем учётной записи пользователя. Данная группа применяется 
как первичная группа и будет задана идентификатором в учётной записи пользователя, 
расположенной в файле /еіс/раззѵѵсі. Учётная запись пользователя может входить более чем 
в одну группу, тогда имена таких групп (в ОССН данные группы называются вторичными) 
будут находиться в файле /еіс/дгоир. 

Как правило, файлы, владельцами которых являются учётные записи пользователей, 
хранятся в соответствующих им домашних каталогах, находящихся в каталоге ІІіоте. При 
этом во время первого входа в ОССН с заданными уровнем доступа (N0/711), уровнем 
целостности (N0/7/2) и набором неиерархических категорий (N0/7/3) (например, 0x2 - вторая 
категория) создается уникальный каталог с именем вида 
/Іюте/.рф/омя_пользователя/Мот1 ІNот2сNотЗЮxО, что позволяет распределить по 
каталогам файлы (в том числе документы) в зависимости от их уровней конфиденциальности 
и целостности. Доступ субъект-сессий (процессов), функционирующих от имени других 
учётных записей пользователей, к домашнему каталогу в ОССН версии 1.6 может быть 
ограничен с использованием как параметров (меток конфиденциальности) мандатного 
управления доступом, так и дискреционных прав доступа. 

При работе от имени учётной записи администратора в ОССН версии 1.6 желательно 
использовать только высокий уровень целостности (по умолчанию он равен 63) и 
минимальный уровень конфиденциальности в связи с особенностями монтирования его 
домашнего каталога. 

Данные об учётных записях пользователей и группах хранятся в файлах /еіс/раззѵѵсі и 
/еіс/дгоор соответственно, структура которых описана в главе 1. Если в файле /еіс/раззѵѵсі 


для некоторой учётной записи пользователя вместо пароля указан символ «х», то свёртка 
пароля находится в файле /еіс/зііасіоѵѵ. Его структура представляет собой список, каждая 
строка которого состоит из элементов, разделённых символом «:», среди которых: число дней 
с 1 января 1970 г. до дня последнего изменения пароля, минимальное число дней действия 
пароля со дня его последнего изменения, максимальное число дней действия пароля, за 
сколько дней до устаревания пароля ОССН начнёт выдавать предупреждения, число дней со 
времени обязательной смены пароля до блокировки учётной записи пользователя, день 
блокировки учётной записи пользователя. 

Для администрирования параметров учётных записей пользователей используются 
следующие команды и утилиты (примеры применения которых рассмотрены в главах 1 и 3): 

• изегадд и аМизег — команды добавления учётной записи пользователя; 

• раззѵѵсі — команда смены пароля учётной записи пользователя; 

• изегтод — команда модификации параметров уже существующей учётной записи; 

• изегсіеі — команда удаления учётной записи пользователя; 

• драззѵѵсі — команда управления группами; 

• аййдгоир — команда создания группы; 

• сіеідгоир — команда удаление группы 

• НІу-асІтіп-зтс —графическая утилита, позволяющая решать весь комплекс задач по 
администрированию учётных записей пользователей и групп, в том числе 
администрировать параметры мандатного управления доступом и мандатного контроля 
целостности. 

В рамках МРОСЛ ДП-модели учётным записям пользователей соответствует 
множество Ц группам — роли из множеств Я и АН, соответствующие перечисленным 
командам де-юре правила преобразования состояний рассмотрены в главе 2. 

При администрировании ОССН необходимо руководствоваться следующими 
рекомендациями. Если в ней включён мандатный контроль целостности на файловой 
системе, то для администрирования ОССН требуется его временно отключить, для чего: 

• снять мандатный контроль целостности с файловой системы ОССН с помощью 
графической утилиты НІу-асІтіп-зтс или командой ипзеПз-ІІеѵ, 

• выполнить необходимые действия по администрированию ОССН (настроить ОССН, 
установить пакеты и т. д.); 

• включить мандатный контроль целостности на файловой системе ОССН с помощью 
графической утилиты НІу-асІтіп-зтс или командой зеПз-іІеѵ; 

• настроить метки целостности установленных системных объектов. 

Для полного выключения режима мандатного контроля целостности: 

• при использовании графического интерфейса с помощью графической утилиты Р/у- 



асітіп-зтс выбрать «Мандатный контроль целостности» и снять отметку «подсистема 
МКЦ»; 

• при использовании терминала Р/у выполнить команду азіга-тіс-сопігоі сіізаЫе. 
Независимо от способа выключения, чтобы изменения вступили в силу необходимо 
перезагрузить ОССН. Полностью выключать мандатный контроль целостности крайне не 
рекомендуется, так как многие механизмы защиты связаны с его включённым режимом, а 
именно: блокировка интерпретаторов, режим блокировки установки бита исполнения — 
посіітосіх, блокировка доступа к конфиденциальной информации и т. д. 

Используемое методическое и лабораторное обеспечение 

• ОССН версии 1.6, в которой создана учётная запись пользователя изег, с параметрами: 
максимальный и минимальный уровни доступа — 0, неиерархические категории — нет, 
уровень целостности — «Высокий», входит в группу администраторов — азігаасітіп 
(вторичная группа), разрешено выполнение привилегированных команд (зисіо). 

• Документация: «Операционная система специального назначения «Азіга Ипих ЗресіаІ 
Есііііоп». Руководство администратора. Часть 1», «Операционная система специального 
назначения «Азіга Ипих ЗресіаІ Есііііоп». Руководство по КОЗ. Часть 1», «Операционная 
система специального назначения «Азіга Ипих ЗресіаІ Есііііоп». Руководство пользователя». 

• Для выполнения работы в течение двух занятий необходимо обеспечить возможность 
сохранения состояния ОССН за счёт применения технологий виртуализации (создания 
виртуальных машин с ОССН). 


Порядок выполнения работы 

1. Начать работу со входа в ОССН в графическом режиме с учётной записью 
пользователя гузег(уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»), 

2. Запустить терминал Р/у из меню «Системные». 

3. Определить текущую учётную запись пользователя с использованием команды 
ѵѵЬоаті. 

4. Проверить наличие права доступа на чтение к файлу /еіс/раззѵѵсі и получить 
следующие данные, выполнив команды са і/е іс/разз ѵѵбѵ\ л и Іезз/ еіс/раззѵѵсі: 

• число параметров учётных записей пользователей (для этого дополнительно можно 
использовать команды ѵѵс и зогі); 

• текущее число учётных записей пользователей; 

• число различных используемых командных интерпретаторов. 

5 . Вывести строку, соответствующую текущей учётной записи пользователя, из файла 
/еіс/раззѵѵсі с использованием команды саі/еіс/раззѵѵсіідгер " л $(ѵѵіюаті):", при этом получить 


следующие данные: 

наличие пароля или свёртки пароля (вывести эти данные командой 
саі/еіс/раззѵѵсіідгер " л $(ѵѵ(юаті) :" \ сиі -д:-(2): 

гооІ@а5Іга:/Ноте/и5ег# саІ/еІс/раз5ѵѵсІ|дгер" Л $(ѵѵИоагпі):" гооІ:х:0:0:гооІ:/гооІ:/Ьіп/ЬазИ 

гооиа)азІга:/Иоте/изег# ехіі 

ехіі 

изег@азІга:~$ саІ/еІс/раззѵѵсІ|дгер " л $(ѵѵИоаті):" 
изег:х:1000:1000:,„ :/Моте/изег:/Ьіп/ЬазМ 

• группа и идентификатор текущей учётной записи пользователя; 

• командный интерпретатор по умолчанию для текущей учётной записи пользователя. 

6. найти отличия исполняемых файлов асісіизег и изегасісі, для чего: 

• определить расположение файлов асісіизег и изегасісі с использованием команд зисіо 
і / ѵііісіі , асісіизег и зисіо ѵѵііісіі изегасісі ; 

• вывести в терминал Р/у тип обоих файлов командой (Не, определить их 
принципиальное отличие. 

7. Добавить две учётные записи пользователей изегі и изег2(с соответствующими 
домашними каталогами) с использованием команд зисіо асісіизег изегі и зисіо асісіизег изег2. 

8. Проанализировать изменения в ОССН, связанные с добавлением новых учётных 
записей пользователей, для чего определить: 

• домашние каталоги учётных записей пользователей по данным файла /еіс/раззѵѵсі', 

• номер алгоритма свёртки паролей учётных записей пользователей по файлу 
/еіс/зкіасіоѵѵ с использованием привилегированного режима или команды зисіо: 
гооІ@а5Іга:/Ноте/изег#саІ/еІс/5Набоѵѵ|дгер " Л изег:"|сиІ -6$ -(26 

• скрипты, которые были перемещены в домашние каталоги учётных записей 
пользователей из каталога /еіс/зкеі, при этом сравнить файлы в каталоге /еіс/зкеі с 
файлами домашних каталогов учётных записей пользователей с использованием команды 
зисіо сШі-з /еІс/зкеІ/кіоте/имя_пользователя\дгер"\лдент\лч ны"; 

• новые группы в файле /еіс/дгоир, 

• идентификаторы новых учётных записей пользователей и групп в файлах /еіс/дгоир 
\л/еіс/раззѵѵсІ. 

9. Осуществить попытку создания учётных записей пользователей изегЗ, изег4 
командами изегасісі изегЗ и изегасісі изег4 без использования команды зисіо, 
проанализировать результат. Выполнить те же действия с применением команды зисіо, 
после чего определить: 

• домашние каталоги учётных записей пользователей по файлу /еіс/раззѵѵсі', 

• были ли созданы домашние каталоги учётных записей пользователей; 


• наличие свёрток паролей учётный записей пользователей по файлам /еіс/раззѵѵсі и 
/еІс/зЬабоѵѵ, 

• новые группы в файле /еіс/дгоир 

• идентификаторы новых учётных записей пользователей в файле /еіс/раззѵѵсі; 

• командный интерпретатор по умолчанию для созданных учётных записей 
пользователей: 

гооЮаз1га:/Ііоте/изег# ІаіІ -1 /еіс/раззѵѵсі|сиІ -сі: -17 /Ьіп/ЬазИ 

ю. Реализовать попытки задать пароль для учётных записей пользователей изегЗ и 
изег4 с использованием команд раззѵѵсі изегЗ и раззѵѵсі изег4 без использования и с 
использованием команды зисіо, сравнить результаты. Определить алгоритм свёртки пароля 
этих учётных записей пользователей по файлу /еІс/зЬасіоѵѵ. 

и. Выполнить дополнительную настройку ОССН для обеспечения возможности входа с 
учётной записью пользователя изегЗ, для чего осуществить следующие действия: 

• выполнить вход в ОССН с учётной записью пользователя изегЗ, введя его имя и 
пароль, проанализировать предупреждения, выдаваемые ОССН; 

• войти в ОССН с учётной записью пользователя изег; 

• создать домашний каталог учётной записи пользователя изегЗ командами зисіо тксііг 
/Іюте/изегЗ, и назначить ему необходимые права доступа: зисіо скоѵѵп изегЗ:изегЗ 
/Іюте/изегЗ, зисіо сіітосі 750 /Ііоте/изегЗ; 

• проверить возможность входа в ОССН с учётной записью пользователя изегЗ; 

• войти в ОССН с учётной записью пользователя изег. 

12. Запустить терминал Ну в «привилегированном» режиме командой зисіо Пу-Іегт. . 

13. Модифицировать параметры учётных записей пользователей: 

• установить домашний каталог учётной записи пользователя изегі командой изегтосі - 
сі /Іюте/изегопе изегі ; 

• установить домашний каталог учётной записи пользователя изег2 командой изегтосі- 
т-сі /Іюте/изегіѵѵо изег2 

• проверить содержимое каталога /іюте командой Із -Іа и определить отличия в 
результатах выполнения команды изегтосі на предыдущих этапах. 

14. Осуществить последовательные попытки входа в ОССН с учётными записями 
созданных пользователей изегі и изег2, при этом выполнить следующие действия: 

• проанализировать причины появления предупреждений при входе в ОССН с учётной 
записью пользователя изегі, сравнив отличия в командах, использованных при 
модификации параметров учётных записей пользователей изегі и изег2; 


вернуть домашний каталог учётной записи пользователя изегі командой изегтосі -сі 


/Іюте/изегі изегі, рассмотреть результат её выполнения, проверить запись о домашнем 
каталоге в файле /еіс/раззѵѵсі; 

• повторно установить домашний каталог пользователя изегі командой изегтод -т -с/ 
/Ьоте/изегопе изегі, проверить результат; 

• проверить возможность входа в ОССН с учётной записью пользователя изегі, выйти из 
ОССН. 

15 . Войти в ОССН с учётной записью пользователя изег( Уровень_0, «Высокий»), 
Запустить графическую утилиту редактирования учётных записей пользователей «Политика 
безопасности» через меню «Панель управления» главного пользовательского меню. 

16 . Открыть раздел настройки локальных пользователей, и для созданных учётных 
записей пользователей изегі, изег2, изегЗ, изег4 произвольно задать их параметры: 

• максимальный и минимальный уровни доступа; 

• минимальные и максимальные наборы неиерархических категорий; 

• максимальный уровень целостности. 

17 . Настроить параметры учётной записи пользователя изег2: 

• установить минимальное число дней между сменой пароля —180 дней и до выдачи 
предупреждения о смене пароля — 5 дней; 

• выбрать максимальный уровень — «Уровень_3»; 

• проверить возможность задать минимальный или максимальный набор 
неиерархических категорий. 

18 . Войти в ОССН с учётной записью пользователя изег2, выбрав уровень доступа 
«Уровень_1». Проверить возможность выбора набора неиерархических категорий и уровня 
целостности. Создать в каталоге «Документы» файл 1 .1x1. Выйти из ОССН. 

19 . Войти в ОССН с учётной записью пользователя изег2вь\драв уровень доступа 
«Уровень_2». Создать в каталоге «Документы» файл 2.1x1: 

Выбор атрибутов безопасности (іі5ег2) 

Уровень конфиденциальности: 

Уровень целостности: 

Категория: Нет 

20. Проверить возможность чтения объектов файловой системы ОССН, владельцем 
которых является учётная запись пользователя изег2( на текущем уровне доступа 
«Уровень_2»): 
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• открыть каталог «Документы» уровне доступа 
«Уровень_1»(Компьютер/Домашний/тас/І1 ІОсООхОЮхО/Документы); 

• открыть файл 1 .1x1, проверив возможность его чтение или записи; 

• выйти из ОССН. 

21. Проверить наличие и возможность чтение объектов файловой системы ОССН, 
владельцем которых является учётная запись пользователяизег2 на текущем уровне 
доступа («Уровень _1 »): 

• войти в ОССН с учётной записью пользователя изег2, выбрав уровень доступа 
«Уровеньі»; 

• проверить возможность открытия каталога «Документы» для уровня доступа 
«У ровенъ_2»(Компьютер/Домашший/тас/І2Юс0х0Юх0/Документы); 

• выйти из ОССН. 

22. Войти в ОССН с учётной записью пользователе изег. Запустить графическую утилиту 
«Политика безопасности». Сравнить списки вторичных групп для учётных записей 
пользователей изег, изегі, изег2, изегЗ, изег4, при этом определив: 

• учётные записи пользователей, являющиеся администраторами (входящими в группу 
азіга-асітіп); 

• учётные записи пользователей, входящие в группу изегз. 

23 . Создать новую учётную запись пользователя изегі0: 

• установить минимальное число дней между сменой пароля — 180 дней и число дней 
выдачи предупреждения до смены пароля — 5 дней; 

• выбрать максимальный уровень доступа — «Уровень_3», минимальный уровень 
доступа — «Уровень 0», уровень целостности — «Высокий»; 

• добавить в список вторичных групп группы азіга-асітіп и Ірасітіп; 

• проверить возможность входа в ОССН с учётной записью пользователя изег 10 с 
уровнями доступа «Уровень_2» или «Уровень_3» (уровень целостности «Низкий»), 

24 . Войти в ОССН с учётной записью пользователя іѵзегІО (уровень доступа — 
«Уровень_0», уровень целостности «Высокий»), Проверить возможность создания новой 
учётной записи пользователя изегі 1 с использованием графической утилиты Ну-асітіп-зтс 
без использования и с использованием команды зисіо. Выйти из ОССН. 


25 . Войти в ОССН с учётной записью пользователя изегі с уровнем доступа — 
«Уровень_0». Осуществить попытки запуска графической утилиты «Политика 
безопасности» через главное пользовательское меню и запуска её с использованием 
терминала Р/у командой Ну-асітіп-зтс. Проанализировать результаты и предупреждения 
ОССН. 

26 . Осуществить переключение между сеансами различных учётных записей 
пользователей без выхода из ОССН: 

• через меню «Завершение работы» главного пользовательского меню перейти в 
подменю «Сессия» и далее «Отдельная» и войти в ОССН с учётной записью пользователя 
изег(уровень целостности «Высокий»); 

• в аналогично вернуться и далее закрыть сеанс от имени учётной записи пользователя 
изегі . 

27 . С использованием графической утилиты «Политика безопасности» заблокировать 
пароль учётной записи пользователя изегі. Проверить изменения файлов /еіс/раззѵѵсі и 
/еіс/зііасіоѵѵ, осуществив следующие действия: 

• в терминале Р/у выполнить команды зисіо саі/еіс/раззѵѵсі и зисіо саі/еіс/зііасіоѵѵ - , 

• проверить наличие блокировки учётной записи пользователя по файлу /еіс/зііасіоѵѵ 
(должен быть установлен знак «!» в начале свёртки пароля); 

• проверить функционирование блокировки путём осуществления попытки входа в ОССН 
в отдельном сеансе от имени учётной записи пользователя изегі ; 

• снять блокировку (выполнить удаление пароля и блокировки входа, задать повторно 
пароль) и проверить возможность входа в ОССН с учётной записью пользователя изегі . 

28 . Выполнить удаление учётных записей пользователей: 

• удалить учётную запись пользователя изегі 0 с использованием графической утилиты 
«Политика безопасности»; 

• удалить учётную запись пользователя изег2командой зисіо сіеіизег изег2; 

• удалить учётную запись пользователя изег/командой зисіо изегсіеі изегі; 

• проверить наличие домашних каталогов учётных записей пользователей изегі и изег2, 
после чего с использованием справочной информации по команде изегсіеі определить её 
параметры, позволяющие удалять содержимое домашнего каталога учётной записи 
пользователя; 

• удалить домашние каталоги учётных записей пользователей изег1\л 
изег2непосредственно командами гт -г /Іюте/изегопе и гт -г /Іюте/изеПѵѵо, осуществив 
попытки удаления без использования и с использованием команды зисіо; 

• проверить наличие домашних каталогов учётных записей пользователей изегі, изег2 и 


изегі О в каталоге /Іюте/.рф. 

29 . Создать новые группу дгоирЗ (с использованием графической утилиты «Политика 
безопасности») и группу дгоир4(командой зидо аМдгоир дгоир4, выполненной в терминале 
Ну). 

30. Добавить учётную запись пользователя изегЗво вторичную группу дгоирЗ командой 
изегтосі -а -О дгоирЗ изегЗ и во вторичную группу дгоир4 с помощью графической утилиты 
«Политика безопасности». Проверить включение учётной записи пользователя изегЗ в 
группы дгоирЗ и дгоир4 путем просмотра содержимого файла /еіс/дгоир командами 
саі/еіс/д гоир/дгер"фгоирЗ" и саІ/еІс/дгоир\ дгер" л дгоир4". 

31. Выполнить удаление учётной записи пользователя изегЗ из группы дгоирЗ с 
использованием графической утилиты «Политика безопасности» и из группы дгоир4 
командой драззѵѵсі -сІизегЗ дгоир4. 

32 . Удалить группу дгоирЗ командой зисіо сіеідгоир дгоирЗ в терминале Р/у и группу 
дг оир4 с помощью графической утилиты «Политика безопасности». 

33. Изучить порядок хранения параметров мандатного управления доступом и 
мандатного контроля целостности для учётных записей пользователей. Для этого 
выполнить следующие действия: 

• определить уровни доступа, заданные в ОССН, для этого вывести в терминал Р/у 
содержимое файла /е1с/рагзес/тас_ІеѵеІз; 

• определить неиерархические категории, заданные в ОССН, для этого вывести в 
терминал Р/у содержимое файла / е1с/рагзес/тас_са1едогіез; 

• определить идентификатор учётной записи пользователя изегі по файлу 
/е/с/раззѵкс/командой саІ/еіс/раззѵѵсІ\ дгер" Л изег 1 :"| сиі -сі : -/3; 

• считать параметры мандатного управления доступом и мандатного контроля 
целостности для учётной записи пользователя изегі командой 

са!/еІс/рагзес/тассІЬ/$(саІ/еІс/раззѵѵсІ\дгер'' А и5ег1 :"| сиі -б: -13) и проверить их соответствие 
данным, отображаемым в графической утилите «Политика безопасности». 

Содержание отчёта о выполненной работе 
В отчёте о выполненной работе необходимо указать: 

1. Полный перечень использованных команд с кратким описанием их назначения. 

2. Примеры выполнения команд, которые были использованы в ходе работы с 
описанием результатов их выполнения. 

3. Описание порядка работы с графической утилитой «Политика безопасности» (Ну- 
асітіп-зтс) при осуществлении следующих действий: 

• создание новых учётной записи пользователя или группы; 

• удаление существующих учётной записи пользователя или группы; 


• добавление учётной записи пользователя в существующую группу; 

• добавление учётной записи пользователя в группу администраторов ( азіга-асітіп ); 

• изменение параметров мандатного управления доступом и мандатного контроля 
целостности. 

4. Список и назначение системных файлов, связанных с хранением параметров учётных 
записей пользователей, групп, параметров мандатного управления доступом и мандатного 
контроля целостности. 

Контрольные вопросы 

1. Какие имеются особенности создания учётных записей пользователей с 
использованием команд аМизег, изегасід и графической утилиты «Политика безопасности» 
(Ну-асітіп-зтс), в том числе: 

• какой группе должна принадлежать учётная запись пользователя, чтобы была 
возможность выполнения команды асісіизег? 

• какими командами создаётся учётная запись пользователя, и какие дополнительные 
параметры при этом вводятся? 

• какие ограничения накладываются на пароль учётной записи пользователя при его 
создании? 

• в какие группы автоматически добавляется учётная запись пользователя? 

2. Как выполнять привилегированные команды? 

3. Создаются ли домашние каталоги учётных записей пользователей при добавлении их 
с использованием графической утилиты «Политика безопасности»? 

4. Создаются ли домашние каталоги учётных записей пользователей при их добавлении 
с использованием команд аМизег и изегаМ? 

5 . Какие минимальный и максимальный уровни доступа задаются по умолчанию для 
учётных записей пользователей, создаваемых командами асісіизег и изегасісі? 

6. Какими способами можно добавить или удалить учётную запись пользователя из 
группы? 

7. Каким образом организовано хранение сущностей файловой системы ОССН, 
созданных процессами, обладающими различными уровнями доступа? 

8. Где и в каком формате хранятся параметры мандатного управления доступом и 
мандатного контроля целостности, заданные в ОССН? 

9 . Где и в каком формате хранятся параметры мандатного управления доступом и 
мандатного контроля целостности для учётных записей пользователей? 

10. Какой командой задаётся максимальный набор неиерархических категорий для 
текущей учётной записи пользователя? 

п. Каким образом осуществляется переход от текущего сеанса к сеансу, 


функционирующему от имени другой учётной записи пользователя? 

12 . Позволяют ли команды изегасісі и аМизегзадаватъ параметры мандатного 
управления доступом и мандатного контроля целостности для создаваемых учётных 
записей пользователей? 


4.2. Лабораторная работа № 2. 

Настройка параметров мандатного управления 
доступом и мандатного контроля целостности 
Цель работы 

Освоить администрирование основных параметров мандатного управления доступом 
и мандатного контроля целостности в ОССН с применением графических утилит и 
консольных команд. 

Время выполнения работы 4 академических часа. 

Краткие теоретические сведения 

В ОССН наряду с традиционной для ОС семейства Ипих системой дискреционного 
управления доступом реализована система мандатного управления доступом и мандатного 
контроля целостности на основе МРОСЛ ДП-модели, рассмотренной в главе 2. С этим 
связано наличие у сущностей ОССН (файлов, каталогов) мандатных меток 
конфиденциальности и целостности. 

Параметрами мандатного управления доступом (мандатной меткой) являются 
следующие элементы: 

• уровень доступа или конфиденциальности (соответствует уровню конфиденциальности 
сущности или доступа субъект-сессии); 

• набор неиерархических категорий сущности и субъект-сессии; 

• уровень целостности сущности и субъект-сессии; 

• специальные атрибуты сущности (СС/ѴЯ, СС/ѴЯ/, Е.НоІе, ѴѴ-НоІе) 

При установке ОССН (по умолчанию) задаются следующие параметры мандатного 
управления доступом и мандатного контроля целостности: 

• 2 непосредственно используемых уровня целостности («Низкий» значение 0, «Высокий» — 
63); 

• 4 уровня доступа/конфиденциальности («Уровень_0» значение 0, «Уровень_1» — 1, 
«Уровень_2» — 2, «Уровень_3» — 3); 

• неиерархические категории — «Категория_1», «Категория_2». 

Мандатное управление доступом процессов (субъект-сессий) к ресурсам (сущностям) 
основано на реализации соответствующего механизма в ядре ОССН. При этом принятие 
решения о запрете или разрешении доступа субъект-сессии к сущности осуществляется в 
соответствии с правилами, описанными в рамках МРОСЛ ДП- модели, и зависит от 
запрашиваемого вида доступа (чтение, запись, применение права доступа на выполнение) и 
мандатного контекста (используемых в запросе уровней конфиденциальности, доступа и 
целостности). 

Для администрирования параметров мандатных управления доступом и контроля 



целостности применяются следующие команды и графические утилиты (примеры 
использования которых рассмотрены в главах 1 и 3): 

• рфі-изег — команда просмотра и изменения допустимых мандатных уровней и 
неиерархические категорий учётных записей пользователей; 

• рсірі-іііе — команда установки параметров мандатного управления доступом на сущность 
файловой системы; 

• рдр-ісі — команда вывода параметров мандатных управления доступом и контроля 
целостности для текущей сессии; 

• изегіеѵ — команда просмотра и редактирования уровней доступа, заданных в ОССН; 

• изегсаі — команда просмотра и редактирования неиерархических категорий учётных 
записей пользователей в ОССН; 

• изегсарз — команда просмотра и редактирования привилегий учётных: записей 
пользователей; 

• ііу-асітіп-зтс — графическая утилита, позволяющая решать весь комплекс задач по 
администрированию учётных записей пользователей и групп, в том числе 
администрировать параметры мандатных управления доступом и контроля целостности. 

Используемое методическое и лабораторное обеспечение 

1. ОССН версии 1.6, в которой создана учётная запись пользователя изег, с 
параметрами: максимальный и минимальный уровни доступа — 0, неиерархические 
категории — нет, уровень целостности — «Высокий», входит в группу администраторов — 
азіга-асітіп (вторичная группа), разрешено выполнение привилегированных команд (зисіо). 

2 . Документация: «Операционная система специального назначения «Азію Ипих 
Зресіаі Есііііоп». Руководство администратора. Часть 1», «Операционная система 
специального назначения «Азію Ипих ЗресіаІ Есііііоп». Руководство по КСЗ. Часть 1», «Опе¬ 
рационная система специального назначения «Азію Ипих Зресіаі Есііііоп». Руководство 
пользователя». 

3. Для выполнения работы в течение двух занятий необходимо обеспечить 
возможность сохранения состояния ОССН за счёт применения технологий виртуализации 
(создания виртуальных машин с ОССН). 

Порядок выполнения работы 

1. Начать работу со входа в ОССН в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»), 

2 . Запустить графическую утилиту редактирования учётных записей пользователей 
«Политика безопасности» через меню «Панель управления» главного пользовательского 


меню. 



з. Модифицировать параметры мандатного управления доступом, для этого 
осуществить следующие действия: 

• открыть раздел «Мандатные атрибуты», «Уровни конфиденциальности» и выбрать «О»: 
Уровень_0» и переименовать данный уровень доступа: «УровеньО»; 

• выполнить создание уровня доступа с именем «Уровень _4», задав значение равное 4, 
после чего проверить наличие записи «Уровень_4» в списке «Уровни 
конфиденциальности»: 



Файл Правка Настройки Помощь 


О 


— Уровни конфиденциально... 

- 0:Уровень_0 
1:Уровень_1 

- 2:Уровень_2 

- 3:Уровень_3 

ІСНМ ВНІІЯЙЯДИЯ — 


й г 

І! 






Я 


Уровень МРД: 4:Уровень_4 

Наименование: Уровень_4 
Уровень: л 


• выполнить обратное переименование: «УровеньО» в «Уровень _0». 

4. Создать учётную запись пользователя изег 1, установив максимальный уровень 
доступа: «Уровень_4». 

5. Выполнить удаление уровня доступа 4 из раздела «Уровни конфиденциальности» 
путём выбора в контекстном меню пункта «Удалить». 

6. Открыть учётную запись пользователя изег\ и в вкладке «МРД» в элементе 
«Максимальный уровень» проверить отсутствие записи имени уровня, при этом, в списке 
выбора уровня «Уровень_4» также будет отсутствовать. 

7. Вывести в терминал Р/у параметры мандатного управления доступом для учётной 
записи пользователя изегЛ . Для этого выполнить следующие действия: 

• запустить терминал Р/у и перейти в каталог / еіс /рагзес /тасдЬ; 

• прочитать параметры учётной записи изеіЛ командой зисіо дгер “ А изег\:”*: 






_Упрааленис политиком безопасности - Уровень МРД: СУропень А 


Файл Правка Настройки Помощь 




- Уровни конфиденциально... 

- 0:Уровень_0 

** І.Уровень.) , 

“ 2:Уровень_2 

- З.Уровень_Э 

С ”• "7 ’г ^ МОЯ "ттгі? ля т-гг гі 


Уровень МРД: 4:Уровень_4 

Наименование; Уровень,4 
Уровень; 4 


• определить максимальный уровень доступа учётной записи изегі командой зидо дгер 
"изегі * | сиі -6: -І5] 

• определить минимальный уровень доступа учётной записи изегі командой зисіо дгер 
"изегі" * /сиі -сі: -ІЗ и проверить его соответствие данным, отображаемым в графической 
утилите «Политика безопасности». 

Создать неиерархические категории с использованием графической утилиты «Политика 
безопасности». Для этого выполнить следующие действия: 

• в разделе «Категории» удалить исходные неиерархические категории; 

• затем создать новую неиерархическую категорию с именем «ОісІе1 1 », «Разряд» — 0; 

• в разделе «Категории» создать новые неиерархические категории: «ОісІеІ2» 

(«Разряд» — 1), «ІІргаѵІепіе» («Разряд» — 2). 

9 . Изменить набор неиерархических категорий с использованием графической утилиты 
«Политика безопасности», для этого выполнить следующие действия в разделе 
«Категории»: 

• выбрать неиерархическую категорию «ОісІе1 1» и ввести наименование «Отдел_1»; 

• аналогично переименовать неиерархические категории «ОісІеІ2» и «ІІргаѵІепіе» в 
«Отдел_2» и «Управление», соответственно; 

• проанализировать возможность одновременного изменения элемента «Разряд». 

• Изменить мандатный уровень доступа с использованием графической утилиты 
«Политика безопасности», для этого выполнить следующие действия: 

• создать новую группу с именем «оііісе 1» и задать первичную группу учётной записи 
пользователя изегі — «оііісе 1»; 

• создать новую учётную запись пользователя изегі) и установить её первичную группу — 

« оііісе 1»; 

• в вкладке «Дополнительные» осуществить попытку выбора минимального набора 
неиерархических категорий — «Отдел_2» и проанализировать результат; 

• в вкладке «Дополнительные» выбрать максимальный уровень доступа — «Уровень_3», 
максимальный набор неиерархических категорий — «Отдел_2», после чего задать 





минимальный набор неиерархических категорий — «Отдел_2»; 

• открыть параметры учётной записи пользователя изегЛ и выбрать максимальный уровень 
доступа — «Уровень_3», максимальный набор неиерархических категорий — «Отдел_1», 
минимальный набор неиерархических категорий — «Отдел_1»; 

• создать учётную запись пользователя гикоНісе 1 и задать первичную группу: «оІТісе 1»: 


# 0 Л Обычные 

Создание пользователя 
Имя: гикоГГісеІ 

Первичная группа: 

Дом. каталог 


/Ьоте/гико(Гісе1 


Л Д Новая 
ІИ) Создать 


• в вкладке «Дополнительные» выбрать максимальный уровень: «Уровень_3», 
максимальный набор категорий: «Отдел_1», «Отдел_2», «Управление». 

• Создать общий каталог для работы от имени учётных записей пользователей изегі , 
изег2, гикоШсеІ в каталоге /Иоте/ѵѵогк. При этом, для работы от имени учётных записей 
пользователей с наборами неиерархическими категорий равными «Отдел_1», «Отдел_2» и 
«Управление» выделить отдельные каталоги «о/с/е/ 1», «о/с/е/2» и «ирг» соответственно. При 
этом обеспечить хранение файлов с различными уровнями конфиденциальности в 
каталогах с использованием специального атрибута СС/ѴЯ, для чего осуществить 
следующие действия: 

• запустить терминал Р/у в «привилегированном» режиме командой зисіо ііу-іеггп; 

• создать каталог і /ѵогк и задать параметры мандатного и дискреционного управления 
доступом командами: 

тксііг /Іюте/ѵѵогк 

сііоѵѵп изег. о11ісе\ /кіоте/ѵѵогк 

скітосі 750 /Іюте/ѵѵогк 

рфІ-ЯІе 3:0: Отдел_1, Отдел_2, Управление: сспг/Іюте/ѵѵогк 

• создать каталог для работы от имени учётных записей пользователей с набором 
неиерархических категорий равным «Отдел_1» и задать параметры мандатного и 
дискреционного управления доступом командами: 

ссі /Іюте/ѵ/огк 
тксііг о/с/е/1 

сіюѵѵп изег\: оііісе^ о/с/е/1 

сАтос/ 770 о/с/е/1 

рсірі-іііе 3:0: Отдел_1: сспг о/с/е/1 

• создать каталог для работы от имени учётных записей пользователей с набором 
неиерархических категорий равным «Отдел_2» и задать параметры мандатного и 






дискреционного управления доступом командами: 
тксііг оісіеі 2 

скоѵѵп изег2: оііісеі оісІеІ2 

сктосі 770 о/с/е/2 

рфі-іііе 3:0: Отдел_2: сспг 0ІсІеІ2 

• создать каталог ирг для работы от имени учётных записей пользователей с набором 
неиерархических категорий равным «Управление» командами: 

тксііг ирг 

сііоѵѵп гикоііісеі : оііісеі ирг 
сктосі 770 ирг 

рсірі-іііе 3:0: Управление: сспг ирг 

• создать вложенные каталоги У1, У2, УЗ в каталогах оісіеі 1, ОІСІѲІ2, ирг командой: 
тксііг {оісІеІ{І,2}, ирг} /У {1,2,3} 

• установить для каталогов оісіеі 1, о/с/е/2, ирг необходимые уровни (см. команды для 
каталога ирг)\ 

рсірі-іііе 1:0: Управление: 0/ коте/ ѵѵогк/ ирг/У 1 
рсірі-іііе 2:0: Управление: 0/ коте/ ѵѵогк/ ирг/У 2 
рсірі-іііе 3:0: Управление: 0/ к о те/ ѵѵогк/ ирг/У3 
скоѵѵп гикоііісеі : оііісеі ирг/У {1 ,2,3} 
сктосі 770 ирг/У {1,2,3} 

• Выполнить последовательные входы в ОССН с учётной записью пользователя изегі 
(неиерархическая категория — «Отдел_1», уровни доступа 1, 2, 3). При работе на уровнях 
доступа 1,2 и 3 создать в каталоге / коте/ѵѵогк/оісІеІМуровенъХ файлы с именами 11 .1x1, 

12 .іхі, 13. іхі соответственно, и установить дискреционные права доступа с разрешением на 
запись и чтение для группы оііісе 1 в графическом файловом менеджере Р/у (ііу-іт). 

• Выполнить последовательные входы в ОССН с учётной записью пользователя 
изег2 (неиерархическая категория — «Отдел_2», уровни доступа 1,2, 3). При работе на 
мандатных уровнях доступа 1,2 и 3 создать в каталоге / коте/ѵѵогк/оіс!еІ2/уровенъХ файлы 
с именами 21. іхі, 22 .іхі, 23. іхі соответственно, и установить дискреционные права доступа с 
разрешением на запись и чтение для группы оііісе 1 в файловом менеджере Р/у. 12 

• Войти в ОССН с учётной записью пользователя гикоііісе 1 (уровень доступа — 3, 
неиерархическая категория — «Отдел2») и проверить возможность получения следующих 
доступов к файлам: доступ на чтение к файлам 21 .іхі, 22 .іхі, 23 Ахі, доступ на запись к файлу 
23. іхі. 

• Войти в ОССН с учётной записью пользователя гикоііісе 1 (уровень доступа — 2, 
неиерархическая категория — «Отдел_1») и проверить возможность получения следующих 



доступов к файлам: доступ на чтение к файлам 11. іхі, 12. Іхі, доступ на запись к файлу 
1 2.Ш. 

• Войти в ОССН с учётной записью пользователя гикоііісе 1 (уровень доступа — 3, 
набор неиерархических категорий — «Отдел_1», «Отдел_2», «Управление») и проверить 
возможность получения доступа на чтение к файлам 11. Іхі, 12 Лхі, 13 .М, 21 .іхі, 22. іхі, 23. Іхі. 

• Войти в ОССН с учётной записью пользователя гикоііісе 1 (уровень доступа — 3, 
неиерархическая категория — «Управление»), Создать файл иЗ.іхі в каталоге 
/ііоте/ѵѵогк/ирг/ УЗ. 

• Войти в ОССН с учётной записью пользователя гикоііісе 1 (уровень доступа — 3, 
набор неиерархических категорий: «Отдел_1», «Отдел_2», «Управление») и проверить 
возможность получения следующих доступов к файлам: доступ на запись к файлу иЗ.іхі, 
доступ на чтение к файлам иЗ.іхі, 11 .іхі, 12 .іхі, 13 .іхі, 21 .іхі, 22. іхі, 23. іхі. 

• Для доступа к терминалу Р/у настроить включение учётных записей пользователей 
изегі, изег2, гикоііісе'\ во вторичную группу азіга-сопзоіе. Это позволит данным учётным 
записям пользователей запускать терминал Р/у с использованием комбинации ѴѴІп+Н. 

• Вывести в терминал Р/у параметры мандатного управления доступом и мандатного 
контроля целостности для учётных записей пользователей. Для этого выполнить 
следующие действия: 

• войти в ОССН с учётной записью пользователя гикоііісе 1 (уровень доступа — 2, набор 
неиерархических категорий: «Отдел_1», «Управление»); 

• в терминале Р/у выполнить команду рф-ісі -а, проанализировать результат; 

• выполнить избирательный вывод параметров мандатного управления доступом (с 
числовыми значениями) командами рф-ісі -I и рдр-ісі - с; 

• выполнить избирательный вывод параметров мандатного управления доступом (с 
именами) командами рсір-ісі -Іп и рф- ісі -сп. 

• Изменить параметры мандатного управления доступом и мандатного контроля 
целостности учётной записи пользователя гикоііісе'\ . Для этого выполнить следующие 
действия: 

• войти в ОССН с учётной записью пользователя изег (уровень доступа — О, 
неиерархические категории — нет, уровень целостности — «Высокий») и запустить 
терминал Р/у в «привилегированном» режиме командой зисіо ііу-іегт ; 

• изменить минимальный и максимальный уровни доступа учётной записи пользователя 
гикоііісе 1 командой рсірі-изег -1 0:2 гикоііісеі, а также минимальный и максимальный наборы 
неиерархических категорий пользователя гикоііісе 1 командой рсірі- изег -с 0:2 гикоііісе 1; 

• обнулить значения уровней доступа и наборов неиерархических категорий в параметрах 
учётной записи пользователя гикоііісе 1 командой рсірі-изег -х гикоііісе '\ ; 



• установить значения уровней доступа и наборов неиерархических категорий в параметрах 
учётной записи пользователя гикоііісе 1 командой рфі-изег -I 1:3 -с 0:7 гикоііісе 1; 

• Считать параметры мандатного управления доступом и мандатного контроля 
целостности учётной записи пользователя гикоііісеі из файлов настроек. Для этого 
выполнить следующие действия: 

• перейти в каталог / еіс/рагзес/тассіЬ и считать минимальный и максимальный уровени 

доступа командами дгер "гикоііісеі " * / сиі-сі : 3 и дгер "гикоііісеі " * / сиі-сі : -/5 

соответственно; 

• считать минимальный и максимальный наборы неиерархических категорий командами 
дгер "гикоііісеі " * / сиі -сі : -14 и дгер "гикоііісеі" * / сиі-сі: -16 соответственно. 

• Создать и модифицировать мандатные уровни доступа, осуществив следующие 
действия: 

• вывести в терминал созданные уровни доступа командой изегіеѵ и сравнить полученные 
данные с настройками в утилите «Политика безопасности»; 

• добавить новый уровень доступа с именем «Уровень_4» (значение 4) командой изегіеѵ 
Уровень_4 -ас/с/4 и вывести в терминал уровни доступа командой изегіеѵ; 

• выполнить переименование уровня доступа «Уровень_4» в «НовыйУровень» командой 
изегіеѵ Уровень_4 — гепате НовыйУровень; 

• добавить возможность работы от имени учётной записи пользователя гикоііісе 1 на уровне 
доступа 4 командой рсірі-изег -1 1:4 гикоііісеі ; 

• выполнить попытку изменения значения уровня доступа «НовыйУровень» на 3 командой 
изегіеѵ НовыйУровень— тосіііу 3, проанализировать результат; 

• изменить значение уровня доступа «НовыйУровень» на 5 командой изегіеѵ НовыйУровень 
— тосіііу 5 и вывести в терминал максимальный уровень доступа учётной записи 
пользователя гикоііісеі командой рфі-изег гикоііісеі , проанализировать результат; 

• установить максимальный уровень доступа учётной записи пользователя гикоііісеі 
равным 5 командой рфі-изег -11 :5 гикоііісеі ; 

• удалить уровень доступа с именем «НовыйУровень» командой изегіеѵ НовыйУровень -сі и 
определить максимальный уровень доступа учётной записи пользователя гикоііісеі 
командой рдрі- изег гикоііісеі , проанализировать результат; 

• восстановить набор неиерархических категорий и уровней доступа учётной записи 
пользователя гикоііісеі командой рдрі- изег -11 :3 -с 0:7 гикоііісеі . 

• Создать и модифицировать неиерархические категории: 

• в терминале Р/у, запущенном в «привилегированном» режиме, вывести неиерархические 
категории командой изегсаі ; 

• добавить новую неиерархическую категорию командой изегсаіоІсіеІЗ —ас/с/0x8; 



• переименовать неиерархическую категорию «оІсІеІЗ» в «Отдел_3» командой изегсаі оІдеІЗ 
-гепате Отдел_3; 

• осуществить попытку модификации наборов неиерархических категорий учётной записи 
пользователя гикоііісеі командой рфі-изег -с 0:15 гикоііісе], проанализировать результат; 

• добавить неиерархическую категорию «Отдел_3» в наборы неиерархических категорий 
учётной записи пользователя гикоііісе 1 командой рфі-изег -с 3:Р гикоЯісе'\ , обратить 
внимание на то, что неиерархическая категория задаётся в шестнадцатеричном формате; 

• осуществить попытку изменения значения неиерархической категории «Отдел_3» на 
значение 2 командой изегсаі Отдел_3 -- тосШу 2, проанализировать результат; 

• изменить значение неиерархической категории «Отдел_3» на 0x10 командой изегсаі 
Отдел_3 - тосШу 10; 

• изменить значение неиерархической категории «Отдел_3» на 0x20 командой изегсаі 
Отдел_3 — тосШу 0x20, обратить внимание на то, что независимо от указания типа числа по 
префиксу «0х» (десятичное или шестнадцатеричное) значение неиерархической категории 
задаётся в шестнадцатеричном формате; 

• удалить неиерархическую категорию «Отдел_3» командой изегсаі Отцеп_3 — сіеіеіе ; 

• изменить значение неиерархической категории «Управление» на 0x10 командой изегсаі 
Управление — тосШу 10, проанализировать результат по данным, выводимым командой 
рсірі-изег гикоііісе 1 ; 

• изменить значение неиерархической категории «Управление» на 4 командой изегсаі 
Управление -тосШу А. 

• Для настройки привилегий учётных записей пользователей осуществить следующие 
действия: 

• вывести в терминал заданные в ОССН привилегии учётных записей пользователей 
командой изегсарз, при работе в терминале Р/у в «привилегированном» режиме; 

• запустить графическую утилиту «Политика безопасности» и открыть настройки учётной 
записи пользователя изегі, в вкладке «Привилегии» установить /./шх-привилегии сар_кіІІ, 
сар_Іоѵѵ- пег и Р4Р5ЕС-привилегии рагзес_сар_сНтас, рагзес_сар_зід, после чего 
закончить работу с утилитой: 


Раг5ес 


Привилегии: 0x48 

! Привилегии л 

Разряд 

! О рагзес_сар_ирсіасе а(іте 

7 

' 1_1 раг5ес_сар_ип5аГе_зеіХ... 

12 

' 0 раг5ес_сар_зитас 

14 

! !.И| раг5ес_сар_5Ід 

б 
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• вывести привилегии учётной записи пользователя изегі командой изегсарз изег 1; 

• в графической утилите «Политика безопасности» открыть параметры учётной записи 
пользователя изег, в вкладке «Привилегии» выбрать Ипих-привилегии сар-кіІІ, сар^оѵѵпег и 
Р/\Я5ЕС-привилегии рагзес_сар_сІітас, рагзес_сар.зід-, 

• запустить терминал Р/у в «непривилегированном» режиме командой Ну-іегт и осуществить 
попытку запуска команды изегсарз', 

• определить расположение файла изегсарз командой і /ѵііісіі изегсарз, выполненной из 
«привилегированного» режима, а затем выполнить в «непривилегированном» режиме 
команду /изг/ зЫп/изегсарз, проанализировать результат; 

• запустить терминал Ну в «привилегированном» режиме командой зисіо ІІу-іегт и 
выполнить модификацию /./шх-привилегий и РАРЗЕС-приеилегий командами: 
изегсарз -1 9 изегі ; 

изегсарз -т 2 изегі ; 
изегсарз -т 11 изегі : 

гооШазіга : /Н изегсарз -1 9 изегі 

1 і пих-приВилегии: 

0 сар_сЬошп 
3 сар_Еоипег 

гооІШазІга :/Й изегсарз -т 2 изегі 


РНРЗЕС-приВилегии: 

1 рагзес_сар_аисІ і і 
гооІШазІга: /Й изегсарз -ш 11 изегі 


РЯРБЕС-приВилегии: 

0 рагзес_сар_Е і 1е_сар 
А рагзес_сар_ і дптас1 ѵ 1 

• с использованием графической утилиты «Политика безопасности» определить 
установленные привилегии и формат параметра модификации привилегий учётных записей 
пользователей (десятичная, восьмеричная или шестнадцатеричная система счисления при 
этом используется?); 

• установить для учётной записи пользователя изегі полный список привилегий командой 
изегсарз -і изегі, затем удалить все привилегии учётной записи пользователя изегі 
командой изегсарз -і изегі -, 

• вывести списки Ипих-привилегий и РАРЗЕС-привилегий командами изегсарз -/. и изегсарз 
-М соответственно. 

Содержание отчёта по выполненной работе 
В отчёте о выполненной работе необходимо указать: 

1. Полный перечень использованных команд с кратким описанием их назначения. 

2 . Примеры выполнения команд, которые были использованы в ходе работы с описанием 





результатов их выполнения. 

3. Описание порядка работы с графической утилитой «Политика безопасности» при 
выполнении следующих действий: 

• создание, изменение и удаление уровней доступа и неиерархических категорий; 

• настройка уровней доступа и неиерархических категорий учётных записей пользователей; 

• создание общих каталогов для совместного использования несколькими учётными 
записями пользователей. 

4. Описание порядка работы и команд, использованных при осуществлении следующих 
действий: 

• настройка уровней доступа и неиерархических категорий в ОССН; 

• настройка уровней доступа и неиерархических категорий учётных записей пользователей. 

5 . Описание особенностей функционирования команд при работе в «привилегированном» 
и «непривилегированном» режимах. 

6. Список и назначение системных файлов, связанных с хранением параметров 
мандатных управления доступом и контроля целостности. 

7. Описание команд при настройке привилегий учётных записей пользователей. 

Контрольные вопросы 

1. Какие уровни доступа и неиерархические категории создаются при установке ОССН? 

2 . Как настроить минимальный и максимальный уровни доступа учётной записи 
пользователя с использованием графической утилиты ііу-асітіп-зтс? 

3. Как добавить новые уровни доступа и неиерархические категории в ОССН? 

4. Какие имеются особенности удаления и модификации уровней доступа и 
неиерархических категорий в ОССН? 

5 . Какие команды используются для создания, модификации и удаления уровней доступа 
и неиерархических категорий в ОССН? 

6. Какие команды используются для настройки привилегий учётных записей 
пользователей? 

7. Как принудительно удалить все привилегии для заданной учётной записи 
пользователя? 

8 . Какие существуют особенности настройки привилегий учётных записей пользователей в 
«непривилегированном» режиме? 



4.3. Лабораторная работа № 3. 

Организация файловой системы ОССН для работы пользователей в 
рамках мандатного управления доступом и мандатного контроля 

целостности 

Цель работы: 

Изучить особенности настройки мандатного управления доступом и мандатного 
контроля целостности к каталогам файловой системы ОССН для совместной работы от 
имени учётных записей пользователей с различными уровнями доступа с документами 
(файлами) с различными уровнями конфиденциальности. 

Время выполнения работы 4 академических часа. 

Краткие теоретические сведения 

В ОССН мандатное управление доступом интегрировано в файловую систему, за счёт 
хранения в ней не только дискреционных прав доступа, но и мандатных меток файлов с 
дополнительными специальными атрибутами, определёнными в рамках МРОСЛ ДП- модели. 
Параметрами мандатного управления доступом и контроля целостности (мандатными 
метками) каждой сущности файловой системы являются: 

• уровень конфиденциальности; 

• набор неиерархических категорий; 

• уровень целостности; 

• специальные атрибуты /ССЛ/Я, ССЛ/Я/, Е - Ноіе, ѴѴ - Ноіе). 

При работе с сущностями файловой системы специальные атрибуты отображаются 
следующим образом: если установлен атрибут ЕНоІе, то указывается еііоіе (ѵѵіюіе для ѴѴ - 
Ноіе), для ССЛ/Я та ССИНІ (данные атрибуты по сравнению заданными в МРОСЛ ДП- 
моделыо атрибутами ССЯ и ССЯ/ в ОССН реализованы инвертированными) — сспг и сспгг 
соответственно; если установлены оба атрибута (СС/ѴЯ и СС/ѴЯ/), то указывается ССЛ/ЯА 
Специальный атрибут ССЛ/Я позволяет осуществлять доступ внутрь контейнера (читать 
содержимое каталога) без учёта уровня конфиденциальности каталога. Аналогично 
используется атрибут ССЛ/Я/, только для работы с мандатным уровнем целостности. 

Наличие у сущности файловой системы мандатных меток целостности позволяют 
дополнительно усилить защиту от несанкционированной модификации файлов, влияющих на 
безопасность ОССН. Это реализуется установкой уровня целостности «Высокий» на 
критически важных сущностях (файлах) файловой системы, что предотвращает изменение 
или удаление таких файлов процессами с низким уровнем целостности. 



Для администрирования параметров мандатного управления доступом и мандатного 
контроля целостности файловой системы в лабораторной работе применяются следующие 
команды и графические утилиты: 

•рфІ-ЯІе — команда модификации параметров мандатного управления доступом 
сущностей файловой системы; 

• изегіеѵ — команда просмотра и редактирования уровней доступа, заданных в ОССН; 

• ііу-асітіп-зтс — графическая утилита, позволяющая решать весь комплекс задач по 
администрированию учётных записей пользователей и групп, в том числе 
администрировать параметры мандатных управления доступом и контроля целостности. 

Используемое методическое и лабораторное обеспечение 

• ОССН версии 1.6, в которой создана учётная запись пользователя изег, с параметрами: 
максимальный и минимальный уровни доступа — 0, неиерархические категории — нет, 
уровень целостности — «Высокий», входит в группу администраторов — азіга- асітіп 
(вторичная группа), разрешено выполнение привилегированных команд (зисіо). 

•Документация: «Операционная система специального назначения «Азіга Ипих 8ресіаІ 
Есііііоп». Руководство администратора. Часть 1», «Операционная система специального 
назначения «Азіга Ипих 8ресіаІ Есііііоп». Руководство по КОЗ. Часть 1», «Операционная 
система специального назначения «Азіга Ипих Зресіаі Есііііоп». Руководство 
пользователя». 

•Для выполнения работы в течение двух занятий необходимо обеспечить возможность 
сохранения состояния ОССН за счёт применения технологий виртуализации (создания 
виртуальных машин с ОССН). 

Порядок выполнения работы 

• Выполнить вход в ОССН в графическом режиме с учётной записью пользователя изег 
(уровень доступа — 0, неиерархические категории — нет, уровень целостности — 
«Высокий»), 

• Проверить корректность включения в ОССН мандатного контроля целостности. Для 
этого запустить графическую утилиту «Политика безопасности» через меню «Панель 
управления», «Безопасность» главного пользовательского меню. Открыть «Монитор 
безопасности» и убедиться в корректном статусе параметров «Режим Мандатного 
Контроля Целостности» и «Установленный на ФС высокий уровень Мандатного 
Контроля Целостности». 

• Запустить терминал ЕІу и выполнить следующие команды для создания группы 
пользователей: 

• выполнить попытку создания группы командой асісідгоир Оііісе-, 

• выполнить попытку создания группы командой зисіо асісідгоир 



• Оііісе - 

• проанализировать полученные ошибки и внести корректировки в команду создания группы; 

• создать группу оііісе командой зидо адддгоир оііісе. 

• Запустить графическую утилиту «Политика безопасности» через меню «Панель 
управления», «Безопасность» главного пользовательского меню. 

Разрешить работать учётной записи пользователя изегцо мандатного уровня доступа 3 
и с любыми созданными в ОССН неиерархическими категориями. 

• Создать следующие учётные записи пользователей: 

• учётную запись пользователя тападегі, задав ей минимальный уровень доступа 
«Уровень_1», максимальный уровень доступа «Уровень_2» (при этом выявить правильную 
последовательность задания данных уровней), минимальная и максимальная 
неиерархическая категория «Категория.!.» (при этом обратить внимание на необходимость 
задания минимальной неиерархической категории); 

• учётную запись пользователя тападег?, задав ей минимальный уровень доступа 
«Уровень.1», максимальный уровень доступа «Уровень_2», минимальная и максимальная 
неиерархическая категория «Категория 74 »; 

• с использованием команды зисіо установить для учётной записи пользователя тападег? 
первичную группу оііісе, затем установить для учётной записи пользователя тападегі 
первичную группу оііісе (при этом использовать команды типа изегтосі -б оііісе имя- 
пользователя). 

• Создать каталог для работы пользователей с различными мандатными уровнями 
доступа, для этого осуществить следующие действия: 

• создать каталог /ііоте/зііаге и установить на него мандатные атрибуты 2:0:3: ССЛ/Я/4 
командой рсірі-іііе 2:0:3: ССЛ/Я/\ /ііоте/зііаге\ 

• разрешить пользователям группы оііісе записывать и читать каталог / ііоте/зііаге: зеііасі - 
тд:оііісе:тх /ііоте/зііаге-, 

• создать каталоги оісіеІІ и оісіеІ2 внутри каталога / ііоте/зііаге', 

• назначить дискреционные права доступа для каталогов /ііоте/ зііаге/оісіеІІ и 
/ііоте/зііаге/оісІеІ2: зеііасі -т д:оііісе:гѵѵх /ііоте/ зііаге/ оісіеІІ и зеііасі -т д:оііісе'.гѵ/х 
/ііоте/зііаге/оісіеІ2\ 

• установить мандатные атрибуты 2:0:1: ССЛ/ЯЛ и 2:0:2: ССЛ/Я/4 для каталогов оісіеІІ и. оісІеІ2 
соответственно. 

8. Настроить каталоги оісіеІІ и оіс!еІ2цпя работы пользователей с различным мандатным 

уровнем доступа: 

• создать каталоги «ДСП» и «С» внутри каталогов оісіеІІ и оісІеІ2 командой: тксііг-р /ііоте/ 
зііаге/ оісІеІ{І/2} / 



• на каталог «ДСП» внутри каталога оідеІІ назначить следующие метки 1:0:1:0; 

• на каталог «С» внутри каталога оісіеіі назначить следующие метки 2:0:1:0; 

• аналогично создать каталоги в /Ііоте/зІіаге/оІдеІ2\ 

• вывести мандатные метки и дискреционные атрибуты каталога зііаге рекурсивно, после чего 
определить назначение используемых опций команды рф-Із: 

изег@аз1га:~$ зисіо рф-Із /Моте/зМаге/ -МпП 

/Моте/зИаге/: 

итого 16 

<±ихгиіхг-х+т — 4 0 0 2:0:0хІ:0хЗ оісіеіі сігісіхгіііхг-х+т- 4 0 0 2:0:0х2:0хЗ 0ІсІеІ2 
/Іпоте/зИаге/оІсІеІІ : итого 16 

сігихгиіхг-х+т-- 2 0 0 1: 0:0x1:0х0 ДСП сігѵѵхгиіхг-х+т-- 2 0 0 2:0:0хІ:0х0 С 
/Іпоте/зИаге/оІсІеІІ/ДСП: итого 0 

/Іпоте/зИаге/оІсІеІІ/С: итого 0 
/Иоте/зІіаге/оІсІеІ2: итого 16 

сігихгіцхг-х+т — 2 0 0 1:0:0х2:0х0 ДСП сігихгихг-х+т- 200 2:0:0х2:0х0 С 
/Іпоте/зИаге/оІсІеІ 2/ДСП: итого 0 
/Иоте/зііаге/оісіеі 2/С: итого 0 

9. Изучить возможность задания дискреционных атрибутов вложенных каталогов 
/Іюте/зііаге с использованием следующих команд: 

• сначала очистить все созданные дискреционные атрибуты: 

• |гооІ@азІга:~Н зейасі -Ь Ліоте/зІіаге/оІсІеІЯ,21 |гооІ@аз1га;~Н зейасі -Ь 

Люте/зІіаге/о1сІеІ{І,21 /{ТІСп,С} 

• выполнить команду их создания: 

гоо1@аз1га:~Н зеІТасІ -т д:о№се:гиіх /Моте/зІіаге/о1сІеІ{1,2>/<ДСП,С> гоо1@аз1га:~Н зеКасі -т 
д:о№се:гих /Иоте/зІіаге/оІсІеІ{1,21 

ш. Модифицировать уровни доступа и неиерархические категории, заданные в ОССН, 
путём переименования неиерархических категорий в «Отделі» и «Отдел2», уровней 0-2 в 
«НС», «ДСП», «С». 

п. Выполнить вход в ОССН в графическом режиме с учётной записью пользователя 
тападегі (уровень доступа — «ДСП», неиерархические категории — «Отделі», уровень 
целостности — «Низкий»): 

• в графической утилите ІІу.Іт выполнить попытки осуществления доступа и создания файлов 
{сІзр-тапІ.М и сізр-сіос-осіі) в подкаталогах каталога /Іюте/зііаге-, 

• выполнить изменение файла дзр-тапі.іхі', 

• осуществить изменение файла дзр-бос.осіі. 



• Выполнить вход в ОССН в графическом режиме с учётной записью пользователя тападегі 
(уровень доступа — «С», неиерархические категории 

• «Отделі», уровень целостности — «Низкий»): 

• в файловом менеджере ІІу-Іт выполнить попытки осуществления доступа и создания 
файлов в подкаталогах каталога /Іюте/зііаге', 

• произвести изменения файла с-тапі.іхі-, 

• выполнить попытку изменения файла сІзр-тапІ.Ш. 

і 2 . Выявить особенность функционирования администратора ОССН, в том числе на 

«Высоком» уровне целостности: 

• выполнить вход в ОССН в графическом режиме с учётной записью пользователя изег 
(уровень доступа — 0, неиерархические категории — нет, уровень целостности — 
«Низкий»); 

• осуществить доступ к каталогу /Іюте/зііаге и его подкаталогам, определить возможность 
доступа на чтение администратора ОССН на «Низком» мандатном уровне целостности к 
сущностям с более высоким уровнем конфиденциальности; 

• осуществить аналогичные действия при работе через зисіо и сравнить результат; 

• выполнить выход и вход в ОССН в графическом режиме с учётной записью пользователя 
изег (уровень доступа — 0, неиерархические категории — нет, уровень целостности — 
«Высокий»); 

• выполнить доступ к каталогу /Іюте/зііаге и его подкаталогам, определить возможность 
доступа на чтение при работе от имени учётной записи пользователя изег на «Высоком» 
мандатном уровне целостности к сущностям с более высоким уровнем 
конфиденциальности; 

• « осуществить аналогичные действия при работе через зидо. 

• отделов, которые могут менять мандатные метки созданных файлов: 

• создать учётную запись пользователя сеоі и задать ей минимальный уровень доступа «НС», 
максимальный уровень доступа «С», минимальная и максимальная неиерархическая 
категория «Отделі»; 

•установить необходимые привилегии ( сар-сіюиіп , рагзес_сар_ сіітас) с использованием 
команды изегсарз сеоі -/1 -т 8; 

• аналогично создать учётную запись пользователя сео2 и задать ей минимальный уровень 
доступа «НС», максимальный уровень доступа «С», минимальная и максимальная 
неиерархическая категория «Отдел2» и аналогичные привилегии. 

і5. Установить для учётных записей пользователей сеоі и сео2: 


• группу по умолчанию оііісе: изегтосі-у оII і се сеоі && изегтосі -д оііісе сео2\ 



• установить дополнительные группы для доступа к Пу-Іегт для учётных записей 
пользователей сеоі, сео2: азіга-сопзоіе (для этого выполнить команду изегтод с 
параметрами -а -О, группой и именем учётной записи пользователя); 

• найти в графической утилите «Политика безопасности» параметр, позволяющий отключить 
доступ к терминалу Р/у для пользователей, и активировать данный параметр. 

іб. Выполнить попытку изменения мандатных меток конфиденциальности файлов: 
выполнить вход в ОССН в графическом режиме с учётной записью пользователя сеоі 
(уровень доступа — «С», неиерархические категории — «Отделі», уровень целостности — 
«Низкий» ); 

создать в каталоге /1юте/зІіаге/о1деІІ/С файл Іезіі.іхі-, 

с использованием меню графического файлового менеджера Ну- іт вывести дискреционные 
и мандатные атрибуты файла іезіі.іхі-, 

выполнить попытку установки мандатных атрибутов файла Іезіі.іхі, при этом необходимо 
сменить уровень с «С» на «ДСП» (ошибка связана с уровнем конфиденциальности файла 
Іезіі.іхі) (см. рисунок на следующей странице); 

выполнить попытку копирования файла Іезіі.іхі в каталог /Коте/зЬаге/ оісІе2І/ДСП (ошибка 
заключается в том, что уровень доступа текущего процесса, осуществляющего копирование, 
выше уровня конфиденциальности каталога назначения, т. е. блокируется запись сверху 
вниз): 

Соойства 

(и(1 о* 

Общие Дискреционные атрибуты Манддтиаа метка Подпись 
Уровень 

Уровень целостности 

категории: 


• копировать файл Іезіі.іхі в каталог /Ііоте/зІіаге/оІдеІІ («С», СС/ѴЯД); 

• сменить мандатные атрибуты файла Іезіі.іхі, при этом необходимо сменить уровень с «С» 
на «ДСП». 

и Выполнить вход в ОССН в графическом режиме с учётной записью пользователя сеоі 
(уровень доступа — «ДСП», неиерархические категории — «Отделі», уровень целостности 
— «Низкий»), 

і8. Скопировать (или перенести) файл іезіі.іхі в каталог / Іюте/зііаге/ оІсІеІІ/ЦСП. 
і9 При необходимости удаления файла / Ііоте/ зііаге/ Іезіі.іхі. войти в ОССН с учётной 
записью пользователя сеоі («ДСП», «Отдел!»). 






го Выполнить вход в ОССН в графическом режиме с учётной записью пользователя 
тападегі (уровень доступа — «С», неиерархические категории — «Отделі», уровень 
целостности — «Низкий»): 

• в файловом менеджере Ну-іт выполнить попытки доступа к файлам и создания файлов в 
подкаталогах «ДСП» и «С» каталога /йоте/зйаге/ оідеіі, 

• выполнить попытку открытия файла сізр-сіос.осіі', 

• выявить возможные ошибки работы с файлом. 

2 і. Возможной причиной того, что файл дзр-дос.оді не может быть открыт с уровня «С» 
является особенность работы ИЬге Оііісе, который создаёт в текущем каталоге файл ~.2ос!с. 
Файл. о. /\пя подтверждения этого необходимо войти в ОССН с использованием терминала 
Р/у с учётными записями пользователей тападегі и тападей: 

• выполнить вход в ОССН в графическом режиме с учётной записью пользователя изег 
(уровень доступа — 0, неиерархические категории — нет, уровень целостности — 
«Высокий»); 

•добавить пользователям тападегі и тападег Л группу азіга- сопзоіе командой: изегтод-а-0 
азіга-сопзоіе тападегі, изег-тосі -а -О азіга-сопзоіе тападегі для возможности запуска 
терминале Р/у1 

• выполнить повторный вход в ОССН в графическом режиме с учётной записью пользователя 
тападегі (уровень доступа — «С», неиерархические категории — «Отделі», уровень 
целостности — «Низкий»); 

• запустить Пу-іегт с использованием комбинации клавиш «Азіга» + «Л». 

гг. С использованием меню графического файлового менеджера Ну-іт создать «Документ 
иЬге Оііісе» в каталоге /йоте/ зііаге/ оісІеІІ/С\ файл с-сіос.осіі, І.осіі. Открыть файл І.осіі, 
перейти в терминале Р/у в каталог / йоте/ зйаге/ оійеІІ/С и вывести содержимое каталога 
(обратить внимание на наличие файла .~2ос!с.І.о): тападегІ@аз1га:/Моте/зИаге/о1сІеІ1/С$ Із - 
Іа итого 28 

2 3. В иЬгеОііісе открыть меню «Сервис», «Параметры», «ИЬ- геОііі.се», «Расширенные 
возможности», «Открыть экспертные настройки». Ввести фильтр: изеіоскіпд. 

24. Изменить значение на іаізе и сохранить изменения. 

25. Ввести фильтр «Іоск» и изменить значения свойств «І/зеОо- ситепіООойоскПІе» и 
«ІІзейоситепіОузіетРіІеіоскІпд» па іаізе. 

26 . Выполнить повторное открытие файла с-дос.оді и проверить отсутствие «/ос/о>-файла. 
г?. Выполнить вход в ОССН в графическом режиме с учётной записью пользователя 

тападегі / тападегі (уровень доступа — «С»/«ДСП», неиерархические категории — 
«Отделі »/«Отдел2», уровень целостности — «Низкий») в доступных комбинациях: 



• в соответствующем режиме проверить возможность доступа на чтение и запись к 
документам, созданным ИЬгеОШсе, с уровнем конфиденциальности, соответствующем 
уровню доступа учётной записи пользователя; 

• проверить необходимые настройки блокировки открываемого документа в настройках 
иЬгеОНісе на текущем уровне; 

• проверить возможность осуществления доступа на чтение (и главное проверить 
возможность открытия) к документам, созданным ИЬгеСЖюе, с уровнем 
конфиденциальности меньше текущего уровня доступа учётной записи пользователя; 

• в конце лабораторной работы вернуть ОССН к начальным настройкам. 

Содержание отчёта по выполненной работе 

В отчёте о выполненной работе необходимо указать: 

• Полный перечень использованных команд с кратким описанием их назначения. 

• Примеры выполнения команд, которые были использованы в ходе работы с описанием 
их результатов. 

• Описание порядка работы с графической утилитой при выполнении следующих 
действий: 

• создание, изменение и удаление уровней доступа и неиерархических категорий; 

• создание и настройка групп пользователей. 

• Описание порядка работы и команд, использованных при осуществлении следующих 
действий: 

• настройка уровней доступа и неиерархических категорий учётных записей 
пользователей; 

• модификация параметров доступа к сущностям файловой системы ОССН; 

• настройка уровней доступа и неиерархических категорий в ОССН. 

• Описание особенностей настройки ИЬге ОНісе для работы с документами в рамках 
мандатного управления доступом. 

• Параметры мандатного управления доступом (метки) для каталогов, предназначенные 
для совместной работы от имени учётных записей пользователей с различным уровнем 
доступа. 

Контрольные вопросы 

• Какая утилита используется для модификации учётных записей пользователей? 

• С какими мандатными атрибутами должен войти администратор ОССН для настройки 
параметров мандатных управления доступом и контроля целостности учётных записей 
пользователей? 

• Какими атрибутами должны обладать каталоги для работы пользователей с 
различным уровнем доступа? 



• Как создать учётные записи пользователей, которые имеют возможность смены 
мандатных меток конфиденциальности файлов, а также владельцев файлов? 

• Как осуществляется доступ к расширенным настройкам ИЬгеОНісе для реализации 
совместного доступа к файлам в рамках мандатных управления доступом и контроля 
целостности? 

Содержание отчёта по выполненной работе 

В отчёте о выполненной работе необходимо указать: 

• Полный перечень использованных команд с кратким описанием их назначения. 

• Примеры выполнения команд, которые были использованы в ходе работы с описанием 
их результатов. 

• Описание порядка работы с графической утилитой при выполнении следующих 
действий: 

• создание, изменение и удаление уровней доступа и неиерархических категорий; 

• создание и настройка групп пользователей. 

• Описание порядка работы и команд, использованных при осуществнии следующих 
действий: 

• настройка уровней доступа и неиерархических категорий учётных записей 
пользователей; 

• модификация параметров доступа к сущностям файловой системы ОССН; 

• настройка уровней доступа и неиерархических категорий в ОССН. 

• Описание особенностей настройки ИЬге ОНісе для работы с документами в рамках 
мандатного управления доступом. 

• Параметры мандатного управления доступом (метки) для каталогов, предназначенные 
для совместной работы от имени учётных записей пользователей с различным уровнем 
доступа. 



4. 4. Лабораторная работа № 4. 

Администрирование ОССН в рамках реализации 
мандатного контроля целостности 

Цель работы 

Выявить особенности администрирования основных параметров мандатного 
управления доступом в ОССН с применением графических утилит и консольных команд при 
активированном мандатном контроле целостности. 

Время выполнения работы 2 академических часа. 

Краткие теоретические сведения 

В ОССН наряду с традиционной для ОС семейства Ипих системой дискреционного 
управления доступом реализована система мандатного управления доступом и мандатного 
контроля целостности на основе МРОСЛ ДП-модели. С этим связано наличие у сущностей 
ОССН (файлов, каталогов) мандатных меток конфиденциальности и целостности. 

Параметрами мандатного управления доступом и контроля целостности (мандатными 
метками) являются следующие элементы: 

• уровень доступа или конфиденциальности (соответствует уровню 
конфиденциальности сущности или доступа субъект-сессии); 

• набор неиерархических категорий сущности и субъект-сессии; 

• уровень целостности сущности и субъект-сессии; 

• специальные атрибуты сущности (ССЛ/Я?, ССЛ/Я/, Е_Но1е, 

1/1/. Ноіе). 

Мандатное управление доступом процессов (субъект-сессий) к ресурсам (сущностям) 
основано на реализации соответствующего механизма в ядре ОССН. При этом решение о 
запрете или разрешении доступа субъект-сессии к сущности принимается в соответствии с 
правилами, описанными в рамках МРОСЛ ДП-модели, и зависит от запрашиваемого вида 
доступа (чтение, запись, применение права доступа на выполнение) и мандатного контекста 
(используемых в запросе уровней конфиденциальности, доступа и целостности). 

Реализация мандатного контроля целостности позволила существенно повысить 
защищенность ОССН. С его применением все учётные записи пользователей, субъект- 
сессии, сущности и роли (при установке ОССН для элементов её файловой системы задаётся 
два мандатных уровня целостности — 0 и 63, хотя их может быть значительно больше, в том 
числе может использоваться вся решётка уровней целостности 0 до 255) чётко разделяются 
на два множества (отсюда и два уровня целостности: «Низкий» < «Высокий»), влияющих на 
целостность и безопасность ОССН или нет. Преимущества мандатного контроля целостности 
аналогичны преимуществам мандатного управления доступом в сравнении с дискреционным 
управлением доступом, т. е. обеспечивается большая ясность правил разделения 



компонентов системы на критичные и некритичные сточки зрения ее целостности, тем самым 
снижается вероятность ошибок. 

Используемое методическое и лабораторное обеспечение 

• ОССН версии 1. 6, в которой создана учётная запись пользователя изег, с 
параметрами: максимальный и минимальный уровни доступа — 0, неиерархические 
категории — нет, уровень целостности — «Высокий», входит в группу администраторов — 
азіга- асітіп (вторичная группа), разрешено выполнение привилегированных команд (зисіо). 

• Документация: «Операционная система специального назначения «Азіга Ипих 8ресіаІ 
Есііііоп». Руководство администратора. Часть 1», «Операционная система специального 
назначения «Азіга Ипих 8ресіаІ Есііііоп». Руководство по КОЗ. Часть 1», «Операционная 
система специального назначения «Азіга Ипих Зресіаі Есііііоп». Руководство пользователя». 
Порядок выполнения работы 

• Включить мандатный контроль целостности в файловой системе ОССН. Для этого 
выполнить вход в ОССН в графическом режиме с учётной записью пользователя изег 
(уровень доступа — О, неиерархические категории — нет, уровень целостности — 
«Высокий»), Запустить графическую утилиту «Политика безопасности» через меню 
«Панель управления», «Безопасность» главного пользовательского меню. Открыть 
«Мандатный контроль целостности» и нажать кнопку «Установить». На данном этапе 
для сущностей файловой системы в соответствии с шаблоном устанавливаются метки 
мандатного уровня целостности «Высокий» (см. рисунок на следующей странице). 
Выполнить выход из ОССН. 

•Проанализировать необходимость использования входа в систему с уровнем 
целостности «Высокий» для администрирования ОССН. Для этого вначале выполнить 
работы по администрированию, используя только уровень целостности «Низкий»: 
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. начать работу со входа в ОССН в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Низкий»); 

. запустить графическую утилиту «Политика безопасности» через меню «Панель 
управления», «Безопасность» главного пользовательского меню. 

• Выполнить попытку модификации параметров мандатного управления доступом, для 
этого осуществить следующие действия: 

. открыть раздел «Мандатные атрибуты», «Уровни конфиденциальности» и выбрать «0: 
Уровень_0» и сделать попытку переименования данного уровня доступа; 

. осуществить попытку создания мандатного уровня доступа; 

. проанализировать результат и причину невозможности выполнения данной операции. 

• Запустить терминал Р/у и выполнить команду рф-ісі -а для получения мандатных 
атрибутов текущего процесса (в данном случае они совпадают с мандатными 
атрибутами текущей сессии), проанализировать результат: 

• выполнить избирательный вывод параметров мандатного управления доступом «с 
числовыми значениями» командами рсір-ісі -I и рдр-ід- с; 

• выполнить избирательный вывод параметров мандатного управления доступом «с 
именами» командами рсір-ісі -Іп и рсір- ісі -СП', 

• определить назначение параметров команд; 

• выполнить попытку запуска команды модификации мандатных уровней: изегіеѵ 
(например, с параметрами Уровень_4 -а 4) и проанализировать полученную ошибку. 

• Запустить терминал Р/у с использованием команды зисіо (использовать комбинацию 
клавиш на клавиатуре «ѴѴіп» + «У?», далее будем её называть «Азію» + «Я») и 
выполнить следующие команды: 

• выполнить команду просмотра мандатных уровней: изегіеѵѵ, 









• определить параметры запуска команды изегіеѵ для создания нового мандатного 
уровня конфиденциальности «Уровень_4» со значением 4 и проанализировать полученную 
ошибку; 

• определить текущие мандатные уровни доступа и целостности с использованием 
команды рдр-ісі, а также определить группы с использованием команды ід: 

гооІ@азІга: Ліоте/изегіІ рф-ісі 

Уровень конф. =0(Уровень_О), Уровень целостности: О(Низкий), Категории=ОхО(Нет) Роли=: 
(Нет: Нет) гоо/@аз/га: /Иоте/іізегН ісі 
иісІ=0(гооІ) дісІ=0(гооІ) группѵѵ=0(гоо1) гооІ@азІга: /Иоте/изег 
Н Й 

•Исходя из особенностей работы от имени учётной записи пользователя 
администратора (изег) в обычном режиме (без использования зисіо) и с использованием 
зисіо, можно сделать вывод, что для администрирования ОССН необходимо получение 
некоторых «дополнительных прав» (т. е. наличие группы с идентификатором О 
недостаточно), которые связаны с реализацией мандатного контроля целостности в 
ОССН. Для изучения особенностей маркировки файлов ОССН метками с высокой 
целостностью выполнить в запущенном терминале Р/у следующие команды: 
вывести в терминал Р/у дискреционные права доступа и параметры мандатного управления 
доступом файлов и каталогов корня файловой системы командой рф-Із -М /; 

• определить опцию команды рф-Із, позволяющую осуществлять вывод меток 
мандатного контроля целостности в числовом формате; 

• с использованием найденной опции определить максимальное значение мандатного 
уровня целостности, заданное для каталога: гооІЕазіга: /И рф-Із -Мп /1 сиі -сі : -1 2 I зогі I дгер 
-ѵ "итого" I ІаіІ -1 63 

• изучить с использованием команды тап и справки назначение команд (рф-Із, сиі, зогі, 
дгер, Іаіі) и использованных опций; 

• выполнить команду получения списка имён файлов и каталогов с уровнем целостности 
«Высокий» для каталога / и /е/с с использованием конвейера и команды дгер; 

• определить уровень целостности файла Іеіс/раззѵѵсІ; 

• выполнить попытки модификации файла / еіс/раззѵѵсі путём добавления в него новых 
записей с использованием текстовых редакторов. 

• Выполнить выход и вход в ОССН в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»), 

• Запустить графическую утилиту «Политика безопасности» через меню «Панель 
управления», «Безопасность» главного пользовательского меню. 



• Выполнить модификацию параметров мандатного управления доступом. Для этого 
выполнить следующие действия: 

• открыть раздел «Мандатные атрибуты», «Уровни конфиденциальности» и выбрать: «3: 
Уровень_3» и переименовать данный уровень доступа: «Уровень. Макс»; 

• создать уровень доступа с именем «Уровень_4», установив значение равное 4; 

• проанализировать результат и причину отсутствия ошибок. 

• Выполнить модификацию параметров учётной записи пользователя изег. 

• открыть раздел «Пользователи», «изег» и выбрать вкладку «МРД»; 

• выполнить попытку изменения минимального уровня доступа учётной записи 
пользователя изег; 

• выполнить изменение максимального уровня доступа учётной записи пользователя 
изег: «Уровень_2», категории «Катего- рия. 1»; 

• выйти из графической утилиты «Политика безопасности». 

• Запустить терминал Р/у и выполнить следующие команды для определения 
особенностей работы в консольном режиме на различных мандатных уровнях 
целостности: 

• выполнить команду получения мандатных атрибутов текущей сессии (с 
использованием команды рдр-ід) и вывести только текущий уровень целостности: изегЕазІга: 
рф-ісІІ аик '{ргіп* $3, $4}' УроВень целостности: 63(63), 

• выполнить аналогичную команду, но с использованием команды рз: 
изег@азІга: зисіо рсірі-рз $(рз аихі дгер Яу-Іегт I дгер -ѵ "дгер" I аик '{ргіпі $2}') I сиі —б : -і 2 
Высокий 

• изучить с использованием тап и справки назначение применённых команд (аѵѵТс, рфі- 
рз, рз). 

• Для определения достаточности уровня целостности «Высокий» при 
администрировании ОССН выполнить следующие команды: 

• вывести содержимое файла / еіс/раззѵѵсі и выполнить попытку его модификации: 
изменить ЗІіеІІ «по-умолчанию» для произвольной учётной записи пользователя; 

• выполнить попытку выдачи на экран содержимого файла /еіс/зііасіоѵѵ. 

• Изучить особенности работы приложений с уровнем целостности «Высокий» для 
пользователя администратора ОССН без и с использованием команды зисіо: 

• запустить терминал Р/у с использованием команды зисіо; 

• сравнить результаты вывода команды рсір-із для каталога /еіс для режима зисіо и без 
него (использовать опцию отображения мандатных меток); 

• вывести содержимое файла / еіс/раззѵѵсі и выполнить модификацию: изменить ЗІіеІІ 
«по-умолчанию» для учётной записи пользователя «изег». 



• Проверить результаты проведённой переконфигурации ОССН: 

• выполнить вход в ОССН от имени учётной записи пользователя изег на уровне доступа 
2 в графическом и консольном режимах; 

• после выполнения соответствующего входа вывести текущие мандатные уровни 
доступа и целостности с использованием команды рдр-ісі. 

•Определить порядок хранения параметров мандатного управления доступом и 
мандатного контроля целостности в ОССН. Для этого проанализировать содержимое 
каталога / еіс/рагзес: 

• с использованием контекстного поиска выделить файлы, содержащие наименования и 
значения мандатных уровней целостности и доступа в ОССН (например, файлы содержащие 
«Высокий»); 

• создать произвольную учётную запись пользователя, установить минимальный 
уровень доступа 1, максимальный — 2, максимальные категории «Категория 74 » и 
«Категория 74 »; 

• определить файлы, содержащие параметры мандатного управления доступом учётных 
записей пользователей (для этого выполнить поиск файлов в каталоге /еіс с именем равным 
идентификатору пользователя); 

• самостоятельно выполнить смену максимального мандатного уровня доступа 
созданной учётной записи пользователя на «Уровень_4» с использованием редактирования 
содержимого найденного файла; 

• проверить результат изменения с использованием графической утилиты «Политика 
безопасности»; 

• проверить возможность входа в ОССН в графическом режиме с созданной учётной 
записью пользователя (уровень доступа — 4, неиерархические категории — нет, уровень 
целостности — «Низкий»); 

• определить файл, используемый для хранения параметров максимального мандатного 
уровня целостности созданной учётной записи пользователя; 

• в конце лабораторной работы вернуть ОССН к начальным настройкам (выполнить 
удаление созданных мандатных уровней доступа и т. п. ). 

Содержание отчёта по выполненной работе 
В отчёте о выполненной работе необходимо указать: 

• Полный перечень использованных команд с кратким описанием их назначения. 

• Примеры выполнения команд, которые были использованы в ходе работы с описанием 
результатов их выполнения. 

• Описание порядка работы с графической утилитой «Политика безопасности» при 
выполнении следующих действий: 



• создание, изменение и удаление уровней доступа и неиерархических категорий; 

• настройка уровней доступа и неиерархических категорий учётных записей 

пользователей. 

• Описание порядка работы и команд, использованных при осуществлении следующих 
действий: 

• настройка уровней доступа и неиерархических категорий учётных записей 

пользователей; 

• настройка уровней доступа и неиерархических категорий в ОССН. 

• Описание особенностей функционирования команд при работе на «Высоком» и 
«Низком» уровнях целостности. 

• Список и назначение системных файлов, связанных с хранением параметров 
мандатного управления доступом и мандатного контроля целостности ОССН и 
пользователей. 

Контрольные вопросы 

• Как из Ну-1егт запустить графическую утилиту «Политика безопасности»? 

• Как с использованием графического интерфейса создать мандатный уровень доступа 
ОССН? 

• Как определить текущие мандатные уровни доступа и целостности сессии 
пользователя? 

• В чем заключаются отличия работы приложений с различным мандатным уровнем 
целостности для пользователя администратора ОССН без и с использованием команды 
зисіо? 

•Как выполнить смену максимального уровня доступа заданной учётной записи 
пользователя с использованием консольных команд? 

• Как определить параметры мандатного управления доступом учётных записей 
пользователей? 

• Какие файлы используются для хранения параметров мандатного управления 
доступом учётных записей пользователей? 



4. 5. Лабораторная работа № 5. 

Настройка механизмов организации замкнутой программной среды. 

Контроль целостности КСЗ 

Цель работы 

Изучить принципы и технологии контроля целостности данных (в том числе комплекса 
средств защиты — КСЗ), реализованных в ОССН. Освоить умения, необходимые для 
решения задач подсчёта носителей контрольных сумм файлов и оптических носителей, 
контроля соответствия дистрибутиву, регламентного контроля целостности и создания 
замкнутой программной среды. 

Время выполнения работы 2 академических часа. 

Краткие теоретические сведения 

АСЗИ на базе ОССН должны обеспечивать функции как аудита доступа к сущностям 
файловой системы, так и контроля целостности (іпіедгііу) данных и содержимого 
исполняемых файлов. Подобный контроль позволяет с достаточной уверенностью конста¬ 
тировать факт отсутствия в данных, обрабатываемых системными процессами ОССН, 
недекларируемых для АСЗИ возможностей. 

Для решения задачи контроля целостности в состав КСЗ ОССН включены средства, 
реализующие частные функции управления целостностью данных: 

• вычисления и проверки контрольных сумм файлов и оптических дисков; 

• контроля соответствия дистрибутиву; 

• регламентного контроля целостности; 

• создания замкнутой программной среды. 

Базовым методом контроля целостности сущностей файловой системы ОССН 
является контроль их модификации путём вычисления контрольных сумм. 

Контрольная сумма — значение, рассчитанное по набору данных путём применения 
определённого алгоритма и используемое для проверки целостности данных при их 
передаче или хранении. Она используется для быстрого сравнения двух наборов данных на 
эквивалентность: с очень большой вероятностью отличающиеся наборы данных будут иметь 
разные контрольные суммы. 

Алгоритмы вычисления контрольной суммы, как правило, делятся на два вида: 

• Алгоритмы общего назначения. К таким алгоритмам, в первую очередь, 
относится циклический избыточный код (Сусііс Несіипсіапсу СМеск, СПС), 
реализацией которого являются алгоритмы СПС8, СПС16, СПС32, 
применяющиеся для проверки целостности цифровых данных при их передаче 


по каналам связи. 



• Криптографические алгоритмы. Эти алгоритмы основаны на процедуре 
хэширования — преобразования входного массива данных произвольной длины 
в выходную битовую строку фиксированной длины. К таким алгоритмам 
относятся, например, семейства алгоритмов ІѴЮ {Меззаде Эідезі АІдогіІМт — 
ІѴЮ2- ІѴЮ6), ЗНА {Зесиге НазИ АІдогіІІпт — 5НА-1,5НА-2), ГОСТ Р 34. 11 (ГОСТ 
Р 34. 11-94, снятый с эксплуатации с 1 января 2013 г. , ГОСТ Р 34. 11-2012 
«Стрибог») и другие. Областью применения этих алгоритмов является 
подтверждение целостности и подлинности передаваемых и хранимых данных. 

В составе КСЗ ОССН включены следующие средства контроля целостности: 

1. Команды, реализующие криптографические алгоритмы: 

• тсібзит (реализация алгоритма МОБ); 

• зНазит (реализация семейства алгоритмов ЗНА-224, 5НА-256, 5НА-384, ЗНА- 
512, ЗНА-512/256 и ЗНА-512/224). 

2. Средства проверки соответствия файловых сущностей ОССН её дистрибутиву: 

• команда дозізшп (реализация алгоритма ГОСТ Р 34. 11-94, ГОСТ Р 34. 11-2012 
256 и 512 битов); 

• графическая утилита (Іу-асІтіп-іпІ-сНеск. 

Указанные команды и утилиты реализуют статический контроль целостности 
файловых сущностей ОССН, включающий следующие компоненты: 

1. Система мониторинга целостности файлов (РІМ — Рііе іпіедгііу топііогіпд) АРІСК (АпоІИег 
Рііе Іпіедгііу СМесКег), реализующая регламентный (периодический) контроль целостности 
файловых сущностей ОССН — вариант динамического контроля целостности. 

2. Механизм контроля целостности исполняемых файлов и разделяемых библиотек формата 
ЕІ_Р при запуске приложений на выполнение. Он реализован в выгружаемом модуле ядра 
ОССН сіід- зід. ѵегі( и обеспечивает: 

• контроль целостности исполняемых файлов и разделяемых библиотек на 
основе их контрольных сумм, вычисляемых в соответствии с ГОСТ Р 34. 11-94, 
ГОСТ Р 34. 11-2012 и электронной подписи, реализованной в соответствии с 
ГОСТ Р 34. 10-2001 и ГОСТ Р 34. 10-2012. Контрольная сумма и электронная 
подпись внедрены в файлы формата ЕІ_Р в процессе сборки ОССН; 

внедрение электронной подписи в исполняемые файлы формата ЕІ_Р, входящие в состав 
устанавливаемого ПО. 

Команды и утилиты статического контроля целостности функционируют в режимах 
вычисления (сотрите) и проверки (сМеск) контрольных сумм файловых сущностей ОССН. 
Например, команда зМазит в режиме вычисления контрольной суммы файловой сущности с 
именем /гооІЛііе с использованием алгоритма 5НА-256 имеет следующий синтаксис: 



зИазит -а 256 /гооІ/ЛІе 

В режиме проверки контрольных сумм файловых сущностей команды статического 
контроля целостности вычисляют их для сущностей, полный путь которых указан в текстовом 
файле с эталонными контрольными суммами, и сравнивают их с эталонными контрольными 
суммами из этого файла. Результатом их выполнения в режиме проверки контрольных сумм 
является передача на стандартный вывод строки формата (в случае совпадения 
контрольных сумм): 

полный_путь_к_файловой_сущности: ОК или (в случае их несовпадения): 
полный_путъ_к_файловой_сущности: РАИЕР 

Например, команда зИазит в режиме проверки контрольных сумм файловых сущностей в 
каталоге /гооі/сіігі, с использованием алгоритма 8НА-256 и при наличии текстового файла с 
эталонными 

контрольными суммами /гооі/сіігі. зИа, имеет следующий синтаксис: 
зИазит -а 256 —с /гооі/сіігі. зМа 

Для вычисления контрольных сумм файловых сущностей ОССН с использованием 
криптографического алгоритма ГОСТ Р 34. 11-2012 256 битов применяется команда дозізит, 
имеющая следующий синтаксис: 
дозізит полный_путъ_к_файловой_сущности 

- о полный_путь_к_файловой_сущности_с_контролъными_ суммами 

Для проверки соответствия модулей установленной ОССН модулям, входящим в 
состав её дистрибутива, используется графическая утилита ІІу-асІтіп-іпІ-сИеск, имеющая 
следующий интерфейс: 


Т» Проверка целостности системы _ □ х 


Файл Фильтры Справка 
Параметры проверки целостности с 

Точка монтирования носителя /тегііа/ссігот ! I П монтировать 


Фильтры 


Принудительно 

Игнорировать 

/Ьооі/.* 

/еіс/.* 

/Ьіп/.* 

/ѵат/.* 

/ІіЬ/.* 

/ішр/ * 

/иіг/ЫпЛ* 

/ргос/ * 

/ІіЬ/вссіігіІу/.* 

/*у */.* 

/еіс/іпіі.сі/ * 

/и5г/5Иагс/р.ігп-сопГід5/.* 

/иѵг/ІіЬДкЬгео(Гісс/$Иаге/гсді5(гу/гпакп.хсс1 


і + 1 . — , 




Отчеты 

««□ 

/Иоте/изег/герогстхі 


НТМИО 

/Ноте/изег/герогТ.НттІ 


ХІИіО 

/Иоте/изег/герогілтІ 



Іаі Не выводить дополнительных запросов ?? Начать проверку 


Проверка не выполнялась Прошло еременшнеиэвестио Осталость еремени:неизаестно 






Для выполнения этой проверки в состав дистрибутива ОССН входит файл дозізитз. 
М, созданный командой дозізит и содержащий список контрольных сумм всех файлов, 
входящих в пакеты программ дистрибутива. Получаемый в результате проверки отчёт 
сохраняется в форматах *. Ъф *. Міт и *. хті. 

Проверка соответствия модулей установленной ОССН модулям, входящим в состав её 
дистрибутива, является вариантом статического контроля целостности и обеспечивает 
контроль целостности файловых сущностей, копируемых в корневой раздел ОССН на этапе 
установки, что позволяет убедиться в отсутствии изменений в файловых сущностях модулей, 
произошедших на этапе их эксплуатации. 

Однако такая проверка является неэффективной для файловых сущностей, 
содержимое которых многократно изменяется в ходе эксплуатации ОССН, например 
конфигурационных файлов. Кроме того, контроль целостности на основе только контрольной 
суммы файла не затрагивает проверку таких атрибутов файла, как временные метки 
(Іітезіатрз), дискреционные атрибуты (МіпітаІ АСЬ и ЕА АСЬ), мандатные метки 
безопасности. Для выполнения расширенного контроля целостности файлов, 
обеспечивающего проверку перечисленных атрибутов файлов, в ОССН используется 
система мониторинга целостности файлов АРІСК, реализующая функции контроля 
целостности файлов и их атрибутов с использованием криптографических алгоритмов ІѴЮ5 
и 8НА-1. В ОССН применяется модифицированный вариант системы АРІСК. дополнительно 
реализующий криптографический алгоритм ГОСТ Р 34. 11 (для приложения дозізит 
дополнительно поддерживаются алгоритмы ГОСТ Р 34. 11 -94 и ГОСТ Р 34. 11 -2012 с длиной 
ключа 256 или 512 битов), а также контроль мандатных меток и атрибутов подсистемы аудита 
безопасности! Дополнительно система АРІСК имеет возможность настройки правил проверки 
целостности каталогов. 

Благодаря интеграции системы АРІСК с сервисом запуска приложений по расписанию 
сгоп имеется возможность выполнения регламентного (периодического) контроля 
целостности заданных файловых сущностей ОССН. 

Система АРІСК имеет следующий интерфейс (для её запуска можно использовать команду 
аТіск-Ік) : 









Конфигурационным файлом системы АРІСК является Іе\с/ аііск. сопі — текстовый файл, 
структурированный по секциям. 

Секция аііаз содержит перечень действий (асііоп) контроля целостности, из которых 
формируются правила контроля каталогов и файловых сущностей: 

############### 

# аііаз зесііоп 
############### 

іі асііоп : а Іізі о! Нет Іо сіпеск : 

# тсІ5 : тсІ5 сіпескзит 

# зіпаі: зііаі сіпескзит 

# сі : сіеѵісе 

# і : іпосіе 

# р : регтіззіопз 
#п:питЬего1 Ііпкз 

# и : изег 

# д : дгоир 

# з : зіге 

И Ь : питЬег о{ Ыоскз # т : іпііте # с : сііте # а : аііте # е : рагзес тас # I: рагзес аисі # розі: 
|озІ 

Типовыми действиями является проверка: 

• контрольных сумм, полученных заданным криптографическим алгоритмом (тсІ5, 
зіпаі); 

• іпосіе (і) каталога или файловой сущности, её размера (зіге) и временных меток 
(гтПіте, сііте, аііте); 

• IIЮ и ѲЮ (изег, дгоир) каталога или файловой сущности, а также прав доступа к 
ней (регтіззіопз). 

Применительно к организации подсистемы безопасности ОССН дополнительно определены 
три действия: 

• е: рагзес тас — контроль целостности мандатных меток безопасности 
файловых сущностей; 

• I: рагзес аисі — контроль целостности данных системы аудита безопасности 
ОССН; 

• дозкдозі — контроль целостности файловых сущностей с использованием 
криптографического алгоритма ГОСТ Р 34. 11. 

В результате этих действий в секции аііаз формируются типовые правила для каталогов 
(РІВ), файлов конфигурации ОССН (ЕТС) и файлов журналов системы аудита (І_одз). 



Например, правило для каталогов вида 
ЭІВ = р + і + п + и + д 

указывает на необходимость выполнения проверки прав доступа, метаданных, количества 
ссылок и других стандартных атрибутов. 

Дополнительно секция асііоп включает правила, специфичные для подсистемы 
безопасности РАВЗЕС — РАВЗЕСопІу, РАВСЕС и ѲОЗТ. Например, правило РАВ8ЕС вида 
РАВЗЕС = р + сІ + і + п + и + д + з + Ь + тсІ5 + т + е +1 указывает на необходимость выполнения 
проверки стандартных атрибутов файловых сущностей с использованием криптографическо¬ 
го алгоритма ІѴЮ5, проверки расширенных атрибутов (меток безопасности и флагов аудита) 
и списков АСІ_ этих файловых сущностей. 

В правиле ѲОЗТ вида ѲОЗТ = р + сІ + і + п + и + д + 5 + Ь + дозі + т + е + I параметр 
дозі указывает на необходимость выполнения проверки стандартных атрибутов файловых 
сущностей с использованием криптографического алгоритма ГОСТ Р 34. 11. 

В секции ТМез Іо зсап задаются полные пути и правила, применяемые к каталогам и файловым 
сущностям, для которых выполняется регламентный контроль целостности. Формат записей 
секции Тііез Іо зсап следующий: 

• ЯІе асііоп — проверяются каталоги, подкаталоги и файловые сущности с 
параметром «действия»; 

• ЯІе — из проверки каталогов и подкаталогов исключается файловая сущность 
ЯІе; 

• = сіігесіогу асііоп — с параметром «действия» проверяется только каталог, и из 
проверки исключаются подкаталоги. 

Например: 

• /Ьооі ѲОЗТ — проверка в каталоге /Ьооі всех подкаталогов и файловых 
сущностей с помощью правила ѲОЗТ; 

• = /ЭІВ — проверка с помощью правила ЭІВ только корневого каталога, исключая 
подкаталоги; 

• !/гоо1/. ЬазИ_Иіз1огу — исключение проверки в каталоге /гооі файловой сущности 
. ЬазН-МзІогу. 

Эталонные значения контрольных сумм и атрибутов файловых сущностей и каталогов 
хранятся в базе данных системы АРІСК в файле с расширением псІЬт. Эта база данных 
создаётся в соответствии с параметрами секции «РІез Іо зсап» файла / еіс/ аТіск. сопР 
Результаты контроля целостности оформляются в виде Іод-файлов и сохраняются: 

• в случае принудительного (инициированного администратором) контроля — в 
каталоге /ѵаг/ІіЬ/аІіск/ агсМіѵе в Іод-файлах с форматом имени аііск. 



УУУУММЭЭННММЗЗ. В аналогичных Іод-файлах сохраняются результаты 
обновления (ирсіаіе) базы данных системы АГІСК; 

• в случае регламентного (периодического, инициированного сервисом стоп) 
контроля — в каталоге / ѵаг/ Іод/ аТіск в Іод-файлах с форматом имени аТіск. Іод. 
N (где N принимает значения от 1 до 7). 

Средство создания замкнутой программной среды в ОССН — невыгружаемый модуль 
ядра ОССН сІідзід_ѵегі( функционирует в трёх режимах (аналогично применяются режимы 
проверки подписи в расширенных атрибутах, т. е. не только для ЕІ_Р-файлов, с ис¬ 
пользованием параметра □ЮЗЮ_ХАТТВ_МООЕ): 

• штатный режим — исполняемым файловым сущностям формата ЕІ_Р и 
разделяемым библиотекам, не имеющим ЭП или имеющим некорректную ЭП, 
исполнение запрещается (ОЮЗІѲ_ЕЕР_МООЕ = 1); 

• режим проверки ЭП в комплексе средств системного ПО — исполняемым 
файловым сущностям формата ЕІ_Р и разделяемым библиотекам, не имеющим 
ЭП или имеющим некорректную ЭП, исполнение разрешается, но при этом 
выводится сообщение об ошибке проверки ЭП (ОЮЗЮ_ЕЕР_МООЕ = 2); 

• отладочный режим для тестирования комплекса средств системного ПО 
(установлен по умолчанию) — ЭП исполняемых файловых сущностей формата 
ЕІ_Р и разделяемых библиотек не проверяется (ОЮЗЮ_ЕЕР_МООЕ — 0). 

Для выбора одного из указанных выше режимов функционирования модуля сіідзід _ ѵегіі" 

необходимо отредактировать конфигурационный файл / еіс/ сіідзід/ сІідзід_іпіІгаті5. сопГ 
Управление модулем сІідзід_ѵегі( осуществляется через графический интерфейс (Іу-асітіп- 
зтс либо через интерфейс файловой системы зузіз с использованием следующих файлов: 

• / зуз/ сіідзід/ епіогсе — в данном файле задаются указанные выше режимы 
работы; 

• /зуз/сіідзід/кеу — файл загрузки мастер-ключа ЭП; 

• /зуз/сіідзід/асісііііопаі — файл загрузки дополнительных ключей ЭП. 

Каждый дополнительный ключ для подписи системного ПО должен быть помещён в 
каталог /еіс/сіідзід/кеуз. 

Создание дополнительных ключей выполняется с помощью команды дрд (<ЗІ\ІІІ Ргіѵасу 
ѲиагсІ), модифицированной для использования криптографических алгоритмов ГОСТ Р 34. 
11-94 и ГОСТ Р 34. 11-2012. 

При администрировании средств контроля целостности данных и средств контроля 
соответствия дистрибутиву, а также при работе со средствами создания замкнутой 
программной среды используются следующие команды: 



• аііск — команда управления параметрами системы контроля целостности 
файловых сущностей; 

• Ьзідп — команда создания и проверки ЭП в файлах формата ЕІ_Р; 

• сІідзід_іпіІгатІ5 — команда загрузки ключей ЭП и инициализация режима ЕпЯэгсе 
модуля сПдзід_ѵегф 

• Яу-асІтіп-іпІ-сМеск — графическая утилита администрирования контроля 
целостности файловых сущностей; 

• дрд — команда работы с сертификатами пользователей; 

• ІзтосІ — команда получения списка загруженных модулей ядра; 

• тосІіпЯэ — команда получения информации о заданном модуле ядра; 

• тсібзит, дозізит, зМазит — команда вычисления контрольных сумм; 

• ирсіаіе-іпіігатіз — команда инициализации начального загрузочного образа 
ОССН (іпіігсі). 

Используемое методическое и лабораторное обеспечение 

1. ОССН версии 1. 6, в которой создана ученная запись пользователя изег, с 

параметрами: максимальный и минимальный уровни доступа — О, 

неиерархические категории — нет, уровень целостности — «Высокий», входит в 
группу администраторов — азіга-асітіп (вторичная группа), разрешено выполнение 
привилегированных команд (зисіо). 

2. Дистрибутив ОССН. 

3. Документация: «Операционная система специального назначения «Азіга І_іпих 
ЗресіаІ ЕсІШоп». Руководство администратора. Часть 1», «Операционная система 
специального назначения «Азіга І_іпих ЗресіаІ ЕсІШоп». Руководство по КСЗ. Часть 
1 ». 

4. Для выполнения этапа работы по п. 43 необходимо наличие дополнительных 
ключей ЭП (ключи должны быть получены у разработчика и подписаны мастер- 
ключом «ЗЗС ВРА ВизВІТесМ (РВІМАВУ ВВТ ВООТ КЕУ 2018)»). 

Порядок выполнения работы 

1. Начать работу со входа в ОССН в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, 
уровень целостности — «Высокий») и запустить терминал РІу в 
«привилегированном» режиме командой зисіо Яу-Іегт. 

2. В домашнем каталоге создать подкаталог сМескзит и скопировать в него все 
файлы (включая вложенные каталоги) из каталога /еіс. 

3. Используя алгоритм ІѴЮ5, вычислить контрольные суммы всех файлов в каталоге 
/Моте/изег/ сМескзит и перенаправить результат их вычисления в файл / Моте/ 



изег / тсІ5 сНеск, а поток с перечнем ошибок в файл /Ноте/изег/еггог. тсІ5, командой 
тсібзит /Поте/изег/сНескзит/ * > /Ноте/изег/тсІбсНеск 2 > /Иоте/изег/ еггог. тсІ5: 
гооі@азІга: /Иоте/изег# саі тсІбсНеск 

470с4сІс7сЬ891415913сІ40а12443814с сІ41сІ8ссІ98ГС0Ь204е9800998ес18427е 

6сІа1827сІ6сІ70с8е2Ье08Ь81338Ь8586Ь 

/Ноте/изег/сНескзит/асІсІизег. соп( /Ноте/изег/сНескзит/асрте/Ноте/изег/сНескзит/аЯск. 
соп( 

61 е28705ЬсШ441 Оеі 82еееЬ5469ЬеІ (Ш43422е875620411 3с5546Ь00сІ529 

21 767*2203сІ324с988256Ь07*2634708 37сІ875е620 170с9есШЗЬ0884Ь23Ь73 

87Ь895се145Ь8090сІ628а1 сІ9а014ЫЬ8 а81 ЬЗП сЫ 97219Ь815942141сЛа94е 

4с0921331 7е4еЗсІсІЗс71 сІ74404еб03сб 

/Ноте/изег/сНескзит/аІіазез 

/Ноте/изег/сНескзит/апасгопІаЬ 

/Ноте/изег/сНескзит/азІга-за^ероІісу. соп{ 

/Ноте/изег/сНескзит/азІга_ѵегз іоп /Ноте/изег/сНескзит/ЬазН. ЬазНгс 
/Ноте/и5ег/сНеск5ит/ЬазН_сотрІеІіоп 
/Ноте/изег/сНескзит/ЬіпсІгезѵрогк Ыаскіізі 

4. Вывести в терминал содержимое файлов /Йоте/ изег/тсіб сНеск и /Ноте/изег/еггог. 
тсіб цепочкой команд саі /Иоте/изег/ тсІбсНеск; саі /Ноте/изег/еггог. тсіб и указать, 
для каких объектов в каталоге / Иоте/изег/ сИескзит контрольные суммы не были 
созданы. 

5. Используя алгоритм ЗНА-512/256, вычислить контрольные суммы всех файлов в 
каталоге /Йоте/ изег/ сИескзит и перенаправить результат вычислений в файл 
/Иоте/изег/зИа512256сИеск командой зИазит -а 512256/Иоте/изег/сИескзит/ * > 
/Иоте/изег/ зИа512256сИеск. Вывести на экран содержимое файла /Иоте/изег/ 
зИабІ 2256сНеск командой Іезз / Йоте/ изег/ зИабІ 2256сИеск. 

6. Используя редактор ѵіт, изменить содержимое файла /Йоте 

/изег/сИескзит/раззѵѵсІ, удалив из него учётную запись суперпользователя (строку 
гооН х: 0: 0: гооі: /гооі: /Ьіп/ЬазИ). 

7. Используя алгоритм ІѴЮ5, проверить контрольные суммы всех файлов в каталоге 

/Иоте/изег/ сИескзит и перенаправить результат проверки в файл 

/Ноте/изегЛиІІсНеск командой тсібзит -с . /тсІбсИеск > / Ноте/изегЛиІІсНеск. 

8. Используя алгоритм ЗНА512/256, проверить контрольные суммы всех файлов в 
каталоге /Иоте/изег/сИескзит и перенаправить результат проверки (с 
добавлением) в файл /Ноте/изегЛиІІ-сНеск командой зИазит -а 512256 -с . 
/зИабІ 2256сИеск »/Йоте/ изегЛиІІсИеск. 



9. Найти в файле /Моте/изег/ІиІІсМеск строки, указывающие на файлы с нарушением 
целостности (содержащие слова ПОВРЕЖДЁН и РАІІ_ЕР), вывести в терминал их 
содержимое и число цепочкой команд дгер 'ПОВРЕЖДЁН ' /Моте/изег/ІиІІсМеск > 
/Моте/ изег/ІтрсМеск; дгер ‘РАІІ_ЕО’ /Моте/изегДиІІсМеск » /Моте/ изегДтрсМеск; ѵѵс 
-I /Моте/изегЛтрсМеск; Іезз / Моте/ изег/ Ітр- сМеск. 

10. Используя алгоритм ГОСТ Р 34. 11-2012 (256 битов), вычислить контрольную 
сумму файла /Моте/изег/сМескзит/зМасІоѵѵ, перенаправить результат проверки в 
файл / Моте/изег/дозІсМеск и вывести в терминал содержимое файла / Моте/ 
изег/дозІсМеск цепочкой команд дозізит /Моте/изег/сМескзит/зМасІоѵѵ -о 
/дозІсМеск; Іезз /Моте/изег/дозІсМеск. 

11 .Установить оптический диск с дистрибутивом ОССН и, используя алгоритм ГОСТ 
Р 34. 11-2012 (256 битов), вычислить его контрольную сумму (по умолчанию файл 
устройства оптического диска /сІеѵ/згО) и перенаправить результат вычисления в 
файл /Моте/изег/ізосМеск командой дозізит -сі /сІеѵ/згО > /Моте/изег/ ізосМеск 
(выполнение команды занимает длительное время). 

12. Запустить графическую утилиту ІІу-асІтіп-іпІ-сМеск и во вкладке «Параметры 
проверки целостности»: 

• выбрать точку монтирования устройства «Азіга Зтоіепзк атсІ64» (по умолчанию 
это, чаще всего, каталоги /тесііа/ссігот или /тесііа/ ссІготО) и выполнить 
монтирование; 

• настроить фильтр проверки целостности в разделе «Принудительно», добавив 
регулярное выражение, содержащее абсолютный путь ко всем файлам каталога 
/изг/ІіЬ: /изг/ІіЬ/*; 

• настроить фильтр проверки целостности в разделе «Игнорировать», удалив 
регулярное выражение, содержащее абсолютный путь к каталогу Дтр; 

• в разделе « Отчёты» задать только текстовый формат файла отчёта, определив 
путь размещения файла герогі. 1x1 в каталоге / Моте/изег/героП; 

• изменить содержимое файла / изг/ зМаге/ бос/ ІіЬсар2/ соругідМІ командой ѵіт /изг/ 
зМаге/ с1ос/ПЬсар2/ соругідМІ, удалив в нем две первые строки: 

Іірзігеат-Сопіасі: Апсігеѵѵ О. Ногдап < тогдап@кегпеІ. огд > Зоигсе: МІІрз: //ѵѵѵѵѵѵ. кегпеі. 
огд/риЬ/Ііпих/ІіЬз/зесигі1у/Ііпих-ргіѵз/ІіЬсар2/ : 62 

• начать проверку и зафиксировать предполагаемое время проверки, перейти во 
вкладку «Состояние» и проконтролировать статус проверки, после окончания 
проверки завершить работу графической утилиты; 

• в файле /Моте/изег/героП. 1x1 найти строки, содержащие текст: «Файлы, 
целостность которых нарушена», «Контр. сумма» и 






«/изг/зЬаге/сІос/ІіЬсар2/соругідЫ», сохранить результаты поиска в файл 
/Ьоте/изег/героП-2 цепочкой команд: дгер ‘Файлы, целостность которых 
нарушена’ /Ьоте/изег/герогі. Іхі -А 4 >/Ьоте/изег/герогІ-2-, дгер ’Контр. сумма’ 
/Ьоте/изег/герогі. Іхі -А 4 » /Ьоте/изег/героП-2; дгер 7изг/зЬаге/сІос/ІіЬсар2 
/соругідЫ’ /Ьоте/изег/герогі. Іхі » /Ьоте/изег/героП-2. 

13. Отредактировать секцию сіігесііѵез конфигурационного файла / еіс/ аііск. сопі 
системы АРІСК, отменив проверку выполняющихся приложений: исходный вариант 

секции сіігесііѵез: гиппіпд_ Іііез : = уез, отредактированный вариант секции 

сіігесііѵез: гиппіпдіііез : = 0. 

14. Отредактировать секцию аііаз конфигурационного файла / еіс/ аТіск. сопі системы 
АРІСК: 

• изменить правило ЕТС, удалив из него проверку размера файловых сущностей 
и добавив проверку времени их модификации: исходный вариант правила: ЕТС 
= р + сІ + і + и + д + 5 + тсІ5, отредактированный вариант правила: ЕТС = р + сІ + 
і + и + д + т + тсІ5; 

• отредактировать правило МуВиІе, удалив из него проверку для файловых 
сущностей количества ссылок на них и добавив проверку контроля целостности 
мандатных меток безопасности, контроля целостности данных системы аудита 
безопасности и контроля целостности с использованием криптографического 
алгоритма ГОСТ Р 34. 11-2012 вместо алгоритма ІѴЮ5: исходный вариант 
правила: МуВиІе = р+б+і+п+и+д+з+Ь+тсІб+т, отредактированный вариант 
правила: МуВиІе = р + сІ + і + и + д + 5 + Ь + дозі + т + е + I. 

15. Отредактировать секцию Іііе зесііоп конфигурационного файла / еіс/ аііск. сопі. 

• заменить для каталога /Ьооі правило проверки СОЗТ на правило проверки 
РАВ8ЕС: исходный вариант: /Ьооі 008Т, отредактированный вариант: /Ьооі 
РАВЗЕС-, 

• добавить для файловой сущности / еІс/ІзІаЬ правило проверки МуВиІе: 
отредактированный вариант: /еІс/ІзІаЬ МуВиІе-, 

• активировать правило проверки по умолчанию для каталога 
/ІіЬ: исходный вариант: #/ІіЬ МуВиІе, отредактированный вариант: /ІіЬ МуВиІе. 

16. Обновить базу данных системы АРІСК с учётом выполненных изменений в секции 
Іііе зесііоп командой аііск -и. 

17. Изменить содержимое файла /еІс/ІзІаЬ, удалив в нем две первые строки. 

18. Запустить графическую утилиту «Контроль целостности файлов» (аііск-ік) 
управления АРІСК из меню «Системные» главного пользовательского меню и 



выполнить принудительную проверку целостности, выбрав действие — сравнение 
с базой. 

19. После завершения контроля целостности: 

• в меню утилиты аЛск-Ік «Файл — история» определить дату и время последнего 
принудительного контроля целостности; 

• найти в каталоге /ѵаг/ІіЬ/аІіск/агсМіѵе Іод-файл, соответствующий выполненной 
принудительной проверке (значение ѴѴѴѴМІѴЮОННММЗЗ в имени Іод-файла 
должно совпадать с найденными в предыдущем пункте датой и временем 
проверки); 

• просмотреть найденный Іод-файл с помощью команды Іезз и в его секции 
#бе1аІесІ сИапдез найти запись о нарушении целостности файловой сущности 
/еІсЛзІаЬ (раздел сіпапдесі Тііе : /еІс/ІзіаЬ); 

• проанализировать найденную запись о нарушении целостности и определить 
параметры, соответствующие действиям (асііоп) нарушения целостности, и их 
текущие значения. 

20. Запустить терминал РІу в «привилегированном» режиме командой зисіо ТІу-Іегт. 

21 .Просмотреть загруженные модули ядра ОССН и вывести в терминал данные о 

невыгружаемом модуле сІід5ід_ѵегі( конвейером команд ІзтосІ / дгер «сІід5ід_ѵегіЬ>. 
Ответить на вопрос: связан ли модуль сНдзід_ѵегі( с другими загружаемыми 
(невыгружаемыми) модулями? 

гоо1@аз1та: /еіс/сіідзід# ІзтосІ | дгер "сІід5ід_ѵегіГ сИдзід_ѵегИ : 491520 0 

• Просмотреть информацию о модуле сІідзід_ѵегі( командой тосііпіо сІідзід_ѵегіР 
Определить расположение модуля сІідзід_ѵегі( и информацию о разработчике. 

• Выполнить импорт открытых ключей, используемых для проверки ЭП файлов. Для 
этого выполнить следующие действия: 

• инициализировать каталог / гооі/ . дпирд при просмотре текущих ключей командой 
дрд — Мзі-зідз; 

• импортировать открытый мастер-ключ «08С ЯРА ВизВІТесМ (РВІМАВѴ ВВТ ВООТ 
КЕУ 2018)» командой дрд — ітрогі / е1с/сПдзід/ргітагу_кеу-2018. дрд; 

• импортировать открытые ключи раПпегз_гЫ_гоо1_кеу_2018. дрд и 
ЬиіІб_зуз1ет_гЫ_гоо1_кеу_2018. дрд (данный ключи используется для подписи 
файлов ОССН), командой дрд -ітрогі /еіс/сІідзід/имя_файла_ключа: 

гооІ@аз1га: /еіс/сіідзід# дрд — Іізі-кеуз 
/гооі/. дпирд/риЬгіпд. кЬх 




риЬ дР256 2018-06-17 [ЗС] 

8066Е980220109783Е20842ЕЮ2В6689А370В8024 
иісі [ неизвестно ] ВРА ВизВІТесМ (ВІІІШ-5У5ТЕМ ВВТ ВООТ КЕУ 2018) 

<таіІ@гизЬіІесМ. ги> 

риЬ дР256 2018-06-17 [ЗС] 

А12Р7В5ВАРСЕ40087Р0410АРС82049РС3675В6РА 
иісі [ неизвестно ] 08С ВРА ВизВІТесМ (РАВТІЧЕВЗ ВВТ ВООТ КЕУ 2018) 

<таіІ@гизЬіІесМ. ги> 

риЬ дР256 2018-06-17 [ЗС] 

8Е839Е2Р389Р882А259Р47997285Е858О8069РР5 
иісі [ неизвестно ^ ЗЗС ВРА ВизВІТесМ (РВІМАВУ ВВТ ВООТ КЕУ 2018) 

<таіІ@гизЬіІесМ. ги> 


• Вывести текущие ключи командой дрд — Іізі-зідз. Определить идентификатор мастер- 
ключа «ЗЗС ВРА ВизВІТесМ (РВІМАВУ ВВТ ВООТ КЕУ 2018)». Используется ли он для 
подписи других загруженных ранее ключей? 
гооІ@азІга: /еІс/сІід5Ід#дрд -Іізі-зідз 
/гооі/. дпирд/риЬгіпд. КЬх 


риЬ дР256 2018-06-17 [ЗС] 

8066Е9В0220Ю9783Е20842В02В6689А370В8024 
иісі [ неизвестно ] ЗЗС ВРВ ВизВІТесМ (ВІЛШ-5У5ТЕМ ВВТ РОСТ КЕУ 2018) 

<таіІ@гизЬіІесМ. ги> 

зід 3 Р2В6689В37ОВ8024 2018-06-17 ЗЗС ВРВ ВизВІТесМ (ВІІІШ-ЗУ8ТЕМ 

ВВТ ВООТ КЕУ 2018) <таіІ@гизЫІесМ. ги> 
зід 7285Е8580В069РР5 2018-06-17 ЗЗС ВРВ ВизВІТесМ (РВІМВВУ ВВТ 

ВООТ КЕУ 2018) <таіІ@гизЫІесМ. ги> 

риЬ дР256 2018-06-17 [ЗС] 

В1 2Р785ВВРСЕ40О87РМ10ВРС82049РС3675В6РА 
иісі [ неизвестно ] ЗЗС ВРВ ВизВІТесМ (РАВТІЧЕВ5 ВВТ ВООТ КЕУ 2018) 

<таіІ@гизЫІесМ. ги> 

зід 3 С82Р49РС3675В6РА 2018-06-17 ЗЗС ВРВ ВизВІТесМ (РАВТІМЕВ8 ВВТ 

ВООТ КЕУ 2018) <таіІ@гизЬіІесМ. ги> 





зід 

7285ЕВ58РВ069РР5 2018-06-17 08С ВРВ ВизВІТесЬ (РВІМАВУ ВВТ 

ВООТ КЕУ 2018) <таіІ@гизЫіесЬ. ги> 

риЬ 

дР256 2018-06-17 [5С]ВЕ839Е2Р389Р882В259Р47997285Е858ЭВ069РР5 

иісі 

[ неизвестно ] ^С ВРВ ВизВІТесЬ (РВІМВВУ ВВТ ВООТ КЕУ 2018) 

<таіІ@гизЬі1есЬ. ги> 

зід 3 

7285Е858ЭВ069РР5 2018-06-17 05С ВРВ ВизВІТесЬ (РВІМВВУ ВВТ 

ВООТ КЕУ 2018) <таі!@гизЬі1есЬ. ги> 


• Проверить корректность ЭП файла /Ып/сІазЬ командой Ьзідп -ѵѵ $(ѵѵЬісЬ сІазЬ'). 
Определить, каким ключом был подписан данный файл по его идентификатору в строке 
«зідпег: ». 

• Переписать открытый ключ /еі с/ сІідзід/ЬиіісІ_5у5Іет_гЫ- гоо1-кеу_2018. дрд в каталог 
/еХс/ сіід зід/кеуз командой ср /е1с/Ьідзід/ЬиіІЬзу5Іет-гЬ1_гоо1_кеу_2018. дрд 
/еіс/сіідзід/кеуз. 

• Перейти в каталог /еіс/сіідзід и изменить файл Сіід5ід_іпі1гат1з. сопі (значение 
□ Ю5Ю_ЕІ_Р_МОЭЕ установить равным 1). 

• Проверить корректность установки данного параметра путём открытия настройки 
«Замкнутой программной среды» в «Панели управления». 

• Проверить корректность ключа путём его загрузки в модуль сІідзід_ѵегі1 командой 
сІід5Ід_іпіІгатІз (для поиска этой команды можно использовать команду ТіпсІ) . 

• Создать дополнительный ключ ЭП командой дрд --1иІІдепега1е-кеу. В диалоге команды 

дрд: 

• выбрать пункт 15 «ѲОЗТ В 34. 10-2012», указать неограниченный срок действия 
дополнительного ключа ЭП, выбрав значение 0; 

• указать параметры ВеаІ Мате: гооізегѵег, ЕтаіІ: гоо1@зегѵег. Іезі и получить ІІзег 
Ю: «гооізегѵег <гоо1@зегѵег. 1ез1>». 

• Вывести текущие ключи командой дрд —Іізі-зідз и определить идентификатор ключа 
«гооізегѵег <гоо1@зегѵег. Іез1>». 

• Скопировать файл /Ьіп/сІазЬ в каталог /гооі, указав при этом новое имя файла 1. еіі. 

• Подписать файл I. еІ( новым ключом «гооізегѵег <гооІ@зег- ѵег. 1ез1>» командой Ьзідп - 
-зідп /гооі/і. еіі. 

• Вывести новую подпись файла командой Ьзідп -ѵѵ / гооі/і. еіі и проверить соответствие 
идентификатора ключа ЭП в строке «зідпег. » данным ключа «гооізегѵег <гоо1@зегѵег. 
1ез1>». 



• Включить штатный режим проверки ЭП с использованием модуля сІідзід_ѵегір 
установив значение ключа □ Ю8Ю_Е1_Р_МОЭЕ = 1 в конфигурационном файле 
/еІс/сПдзід/сІід5ід_іпіігатІ5. сопк 

• Активировать настройки командой зисіо ирсіаіе-іпіігатіз -и -к аІІ, затем выполнить 
перезагрузку и повторный вход в ОССН. 

• Запустить терминал РІу в «привилегированном» режиме командой зисіо Лу-Іегт. 

• Проверить включение штатного режим функционирования модуля сІідзід_ѵегі( (в файле 
/зуз/ сіідзід/ еІМтюсІе должно быть установлено значение «1») командой саі 
/зуз/сІідзід/еІГ_тосІе. 

• Выполнить попытку запуска файла /гооі/і . еір который был подписан с использованием 
ключа «гооізегѵег <гоо1@зегѵег. ІезІ>» (данный ключ не был подписан мастер-ключом 
«^С ПРА НизВІТесН (РПІМАПУ НВТ РЮОТ КЕУ 2018)»), и проанализировать 
выводимые ошибки. 

• Установить значение ключа □ Ю8Ю_Е1_Р_МОЭЕ=0 в конфигурационном файле / еіс/ 

сіідзід/ сіідзід _ іпіігатТз. сопр активировать настройки командой ирсІаІе-іпіігатТз -и -к аІІ, 

затем выполнить перезагрузку и повторный вход в ОССН. 

• В «привилегированном» режиме терминала РІу выполнить команду /гооі/і . ей и 
проанализировать выводимые ошибки. 

• Выйти из запущенного интерпретатора «сіазіп» (файл 1. еіі) командой ехіР Активировать 
настройки командой ирсіаіе-іпіігатіз -и -к аІІ, затем выполнить перезагрузку и повторный 
вход в ОССН. 

• При наличии дополнительных ключей ЭП (ключи должны быть получены у 
разработчика и подписаны мастер-ключом «^С ПРА ПизВІТесИ (РПІМАПУ ПВТ ПООТ 
КЕУ 2018)») выполнить следующие действия (далее имена файлов ключей зідп_риЫіс. 
дрд — открытый ключ, зідп_зесгеР дрд — закрытый ключ): 

• в«привилегированном» режиме терминала РІу выполнить очистку ключей в 
папке /гооі/. дпирд командой гт -г /гооі/. дпирд; 

• импортировать ключи командами дрд-ітрогі зідп_риЫіс. дрд; дрд --ітрогі 
зідпзесгеі. дрд; 

• импортировать открытый мастер-ключ командой дрд — ітрогі / еіс/ сіідзід/ ргітагу 
_кеу_2018. дрд; 

• проверить импорт ключей командой дрд —Іізі-зідз, при этом должно отобразиться 
два ключа; 

• добавить действующий ключ ЭП в модуль сІідзід_ѵегі( командой саі / еіс/ 
сІідзід/ЬиіІсІ_5у5Іет_гЫ_гоо1_кеу_2018. дрд > / зуз/ сіідзід /кеуз; 



• добавить новый ключ ЭП в модуль сІідзід_ѵегі1 командой саі зідп_риЫіс. дрд > 
/зуз/сіідзід/кеуз; 

• выполнить команду есМо "1" > / зуз/ сІідзід/еІМпосІе активации режима проверки 
ЭП файлов; 

• скопировать файл /гооі/і. еіі в новый файл командой ср /гооі/і. еіі /гооі/і зідпесі. 
еіі; 

• выполнить команду /гооі/і. еіі и проанализировать выводимые ошибки (данный 
файл не должен запускаться по причине использования ЭП ключом «гооізегѵег 
<гоо1@зегѵег. 1ез1>»); 

• подписать файл 1 зідпесі. еіі командой Ьзідп -зідп /гооі/1 зідп-есі. еіі, затем 
проверить ЭП командой Ьзідп—ѵѵ/гооі/і зідпесі. еіі; 

• запустить подписанный файл командой /гооі/і зідпесі. еіі и проверить отсутствие 
ошибок; 

• выполнить перезагрузку и повторный вход в ОССН, запустить терминал РІу в 
«привилегированном» режиме командой зисіо ТІу-Іегт; 

• проверить текущий режим модуля сІідзід_ѵегі1 командой саі /зуз/сІідзід/еІМпосІе 
(режим должен быть равен 0); 

• перейти в каталог /гооі, осуществить запуск файлов 1 зідпесі. еіі и 1. еіі, затем 
проанализировать полученные результаты и выводимые ошибки; 

• добавить ключи ЭП в модуль сІідзід_ѵегі1 командой саі /еіс/ сіідзід/ 
ЬиіІсІ_5у5Іет_гЫ. гооі-. кеу_2018. дрд > /зуз/сіідзід/кеуз и саі зідп_риЫіс. дрд > 
/зуз/ сіідзід/ кеуз, осуществить повторный запуск файлов 1 зідпесі. еК, 1. еІ(; а 
затем проанализировать полученные результаты. 

• Создать ключи и выполнить подпись файла конфигурации: 

• запустить терминал РІу от имени учётной записи пользователя изег командой Лу- 
Іегт; 

• скопировать файлы / еіс/раззѵѵсі и / Ьіп/ сІазЬ в каталог ~ и сменить владельца на 
изег: изег; 

• выполнить команду генерации мастер-ключа для подписи в хаКг командой дрд - 
-ІиІІ-депегаІе-кеу, выбрать алгоритм (15) и установить имя: хаКг-кеу; 

• выполнить команду генерации ключа для подписи в хаНг командой дрд —ТиІІ- 
депегаіе-кеу, выбрать алгоритм (15) и установить имя: хаііг-кеу-зідп; 

• выполнить подпись ключа «хаііг-кеу-зідп» командой дрд -зідп-кеу "хаііг-кеу-зідп" 
> хаііг-кеу-зідп. дрд; 

• экспортировать ключ «хаііг-кеу» командой дрд-ехроП"ха11г- кеу" хаііг-кеу. дрд; 



• проверить наличие подписанного ключа «хаКг-кеу-зідп» командой дрд --Іізі-зідз 
(при этом ключ «хаНг-кеу-зідп» должен быть подписан ключом «хаКг-кеу»); 

• запомнить идентификаторы ключей «хаКг-кеу» и «хаНг-кеу- зідп» (8 байтов в 
шестнадцатеричном формате — 16 символов); 

• создать хэш файла -/раззѵѵсі и записать его в расширенные атрибуты командой 
Ьзідп - -ЬазЬ -/раззѵѵсі (обратить внимание, что никаких ключей разблокировки 
секретного ключа при этом не запрашивается у пользователя); 

• создать файл ~/. дпирд/дрд. соп( с содержимым: сІеТаиІІ-кеу идентификатор 
_ключа_хаНг-кеу-зідп; 

• выполнить подпись файла раззѵѵсі командой Ьзідп — зідп ~ /раззѵѵсі; 

• выполнить проверку подписи файла раззѵѵсі командой Ьзідп -ѵѵ ~ /раззѵѵсі; 

• скопировать ключи (хаНг-кеу-зідп. дрд и хаНг-кеу. дрд) для работы с подписями 
файлов в каталог /еІс/сІід5ід/хаиг_кеу5; 

• в графическом файловом менеджере ТІу-Тт перейти в каталог «Домашний» и 
открыть в контекстном меню «Свойства», «Подпись» файла раззѵѵсі; 

• нажать кнопки «Загрузить ключи» и «Информация», при этом проверить 
корректность созданного хэш и наличие подписи. 

Содержание отчёта по выполненной работе 
В отчёте по выполненной работе необходимо указать: 

• Полный перечень использованных команд с описанием их назначения. 

• Примеры выполнения команд, которые были использованы в ходе работы, с 
описанием результатов их выполнения. 

• Описание порядка работы с графическим интерфейсом при выполнении следующих 
операций: 

• конфигурирование обязательных для проверки и игнорируемых путей в 
графической утилите (Іу-асІтіп-іпІ-сЬеск; 

• конфигурирование пути размещения файла отчёта в графической утилите \\у- 
асІтіп-іпІ-сЬеск; 

• просмотр текущих правил проверки в графической утилите «Контроль 
целостности файлов» (айск-ік) системы регламентного контроля целостности 
АРІСК', 

• запуск проверки целостности данных в графической утилите аТіск-Ік. 

• Описание порядка работы с командами при выполнении следующих операций: 

• вычисление контрольной суммы файла с использованием команды тсібзит; 

• вычисление контрольной суммы файла с использованием команды зЬазит; 



• вычисление контрольной суммы файла с использованием команды дозізит; 

• проверка целостности файлов с использованием команды тсібзит; 

• проверка целостности файлов с различными алгоритмами вычисления 
контрольной суммы с использованием утилиты зМазигп. 

• Описание особенностей конфигурирования и режимов функционирования модуля 
сІідзід_ѵегі(. 

Контрольные вопросы 

1. В чем заключается отличие команд тсібзит, зіпазит и дозізит с точки зрения 
вычисления контрольной суммы файлов? 

2. В каком формате организован вывод команд тсібзит, зіпазит и дозізит при 
вычислении контрольной суммы файлов? 

3. Какая из команд тсібзит, зіпазит или дозізит выполняет только вычисление 
контрольной суммы файлов и не выполняет проверку их целостности? 

4. В какой из команд тсібзит, зіпазит или дозізит возможно изменение алгоритма 
хэширования? 

5. Каково назначение файла дозізит. Іхі, и где этот файл располагается? 

6. Какие псевдонимы (аііазез) в конфигурационном файле системы регламентного 
контроля целостности АРІСК соответствуют правилам проверки целостности 
мандатных меток безопасности файлов и контроля целостности данных системы 
аудита безопасности? 

7. Какие правила в конфигурационном файле системы регламентного контроля 
целостности АРІСК сформированы по умолчанию, а какие являются спе¬ 
цифическими для подсистемы безопасности РАВ8ЕС? 

8. В каких средствах контроля целостности используется библиотека ІіЬдозІ? 

9. Как инициализировать базу данных системы регламентного контроля целостности 
АРІСК после внесения изменений в её конфигурационный файл? 

10. Каким образом реализована взаимосвязь системы регламентного контроля 
целостности АРІСК и сервиса сгоп? 

11 .Каким видом модулей ядра ОССРІ является модуль сіідзід _ ѵегіТ? 

12. Какой формат файлов ключей ЭП СПО использует модуль сіідзід. ѵегіі? 

13. Какая специализированная файловая система применяется для хранения данных 
о состоянии и функционировании модуля сІідзід_ѵепІ? 

14. Какой файл сценария командного интерпретатора ЬазИ применяется при 
добавлении дополнительных ключей ЭП для модуля сНдзід_ѵегіІ? 



4.6. Лабораторная работа № 6. 

Настройка сетевого взаимодействия 

Цель работы 

Изучить принципы и порядок конфигурирования сетевого взаимодействия узлов АСЗИ 
на базе ОССН. Освоить навыки решения задач управления сетевыми интерфейсами и 
протоколами, а также маршрутизации пакетов. 

Время выполнения работы 4 академических часа. 

Краткие теоретические сведения 

Взаимодействие узлов АСЗИ между собой и с сетевым оборудованием в сетях с 
пакетной коммутацией на базе стека протоколов ТСР/ІР основано на сетевых службах, 
реализуемых соответствующими процессами в ОССН. Такие процессы на серверных узлах 
АСЗИ создают программные интерфейсы (сокеты), связанные с требуемыми сетевыми 
службами сетевыми портами. Процессы ОССН на клиентских узлах АСЗИ формируют запрос 
на открытие соответствующего сокета с указанием ІР-адреса и сетевого порта серверных 
узлов АСЗИ. Результатом выполнения такого запроса является установление соединения 
между серверными и клиентскими узлами ОССН в рамках заданной сетевой службы. 
Особенностью этого соединения в ОССН является поддержка передачи по нему данных 
мандатного контекста сущностей сетевой службы и субъектов доступа к ней в соответствии с 
ГОСТ Р 58256-2018, при этом монитором обращений выступает подсистема безопасности 
РАН5ЕС. В случаях, когда сетевой сервис не обрабатывает данные мандатного контекста, 
однако осуществляет соединение с процессами ОССН, работающими в различных 
мандатных контекстах, применяется механизм ргіѵзоск. 

Конфигурация сетевых интерфейсов, настройка адресной информации и статической 
маршрутизации пакетов реализуются на-борами команд /Ѵе//оо/5 (пакет пеі-іооіз, в том числе 
команда тіі-іооі ) и Іргоиіе 2 (пакет іргоиіе 2), графической утилитой ііу-асітіп-деѵісе-тападег. 
Для статического конфигурирования параметров сетевых интерфейсов также используется 
конфигурационный файл/ еіс/пеіѵѵогк/іпіегіасез, а для управления запуском приложений 
перед инициализацией и закрытием сетевых интерфейсов — наборы сценариев, 
расположенные в каталогах: /еіс/пеШогк/іі-ир. б, /еіс/пеіѵ/огк/іі-доѵ/п. 6, /еіс/іі-рге-ир. б и Іеіс/іі- 
розі-сіоѵѵп.сі. 

В пакеты іргоиІе2, пеі-іооіз входят следующие команды: 

ір — команда для просмотра параметров и конфигурирования сетевых интерфейсов, сетевых 
адресов, таблиц маршрутизации, правил маршрутизации; 

• агр — команда для просмотра таблиц, /Р-туннелей, адресов групповой рассылки; 

• іс — (ігаіііс сопігоі ) команда для просмотра и конфигурирования параметров 
управления трафиком; 



• 55 — команда для просмотра текущих соединений и открытых сетевых портов. 

Команда ір имеет следующий синтаксис: 
ір имя_объекта название_команды 
где: 

• имя_объекта — логический объект сетевого соединения, над которым 
производятся действия (к таким логическим объектам относятся, например, 
сетевые интерфейсы, адреса, таблицы маршрутизации); 

• название_команды — описатель специфического действия над объектом. 

Например: 

• ір Ііпк зііоѵѵ — вывод текущего состояния (команда зііоѵѵ) сетевых интерфейсов 
(объект Ііпк); 

• ір аМгезз зііоѵѵ — вывод (команда зііоѵѵ) сопоставленных с сетевыми 
интерфейсами ІР- адресов (объект адсігезз)\ 

• ір Ііпк зеі ир еІіі2 — включение (команда зеі ир) сетевого интерфейса, 
связанного с файлом устройства еііі2 (объект Ііпк)] в зисіо ір аМгезз асісі 
192.168.1.1/25ЬгсІ -(- сіеѵ еОіО — добавление(команда асісі) ІР- адреса 
192.168.1.1/25 (объект асісіг) для сетевого интерфейса, связанного с файлом 
устройства еОіО с автоматическим расчётом широковещательного (параметр 
Ьгсі +)адреса (выполнение требует привилегий супер пользователя).Команда 
55 имеет следующий синтаксис:55 название А опции фильтр, где: 

о название А опции — элементы сбора статистики по сетевым соединениям (ТСР, ІЮР, ззіі, 
(Ір, Шр, Шрз) фильтр — указываются опциональные фильтры для выбора статистики. 
Например: 

• 55-5 — вывод информации об открытых сетевых соединениях» 55 -/— вывод 
информации о всех открытых портах; 

• 55 — рі- — вывод информации о всех открытых портах с указанием приложения, 
открывшего порт; 

• 55 -Іа — вывод информации о всех ТСР соединениях;»55 -иа — вывод 
информации о всех ІЮР соединениях. 

• Апплет №ІѵѵогкМападег (/изг/Ып/пт-арріеІ «Сетевые соединения») 
отображает обнаруженные автоматически сетевые интерфейсы и элементы 
управления, с помощью которых имеется возможность: 

• отключить/включить сетевой интерфейс; 

• вызвать меню настроек /Р-адреса сетевого интерфейса; 

• задать этот сетевой интерфейс в сетевом профиле по умолчанию (сіе(аиіі) 



• выполнить настройку доступных сетевых интерфейсов. Команда тіі-іооі 
позволяет контролировать драйвер устройства, связанного с сетевым 
интерфейсом, отображать данные о нем, управлять параметрами драйвера и 
программной конфигурацией устройства. 

В случае использования на узле АСЗИ под управлением ОССН двух и более сетевых 
интерфейсов (например, когда узел является маршрутизатором и шлюзом) требуется 
включение функции «1Р іогѵѵагсііпд», которая позволяет перенаправлять ^-пакеты с одного 
сетевого интерфейса на другой. Включение функции «ІР іогѵѵагсііпд» выполняется путём 
вызова команды вида зузсіі -ѵѵ пеі.ірѵ4-ір-іогѵѵагсі — 1. 

Для того чтобы данный параметр работы ядра устанавливался при загрузке ОССН, 
необходимо раскомментировать строку «пеі.ірѵ4-ір-іогѵѵагсі = 1» в конфигурационном файле 
/еіс/зузсіі.сопі. 

Для использования механизма ргіѵзоск при функционировании сетевого сервиса необходимо 
отредактировать файл / еіс/рагзес/ргіѵзоск. сопі, добавив в него строку, содержащую полный 
путь к исполняемому файлу сервиса. Например, для запуска Р^5-сервера с использованием 
механизма ргіѵзоск файл / еіс/рагзес/ргіѵзоск. сол/должен содержать следующую строку: Іизг/ 
зЫп/ патесі. Кроме того для использования механизма необходимо, чтобы переменная РАТН 
при запуске данного сервиса, содержала путь Іизг/НЬ/рагзес/Ып. Для ОЛ/5-сервера файл 
настроек / еіс/сіеіаиіі/ЫпсІ9 должен содержать строку РАТН—/изг/НЬ/рагзес/&т:$РАТН. 

При настройке сетевого взаимодействия используются следующие команды и графические 
утилиты (примеры применения которых также рассмотрены в главе 3): 

• гоиіе — команда управления маршрутами; о іісопіід — команда управления 
параметрами сетевого интерфейса; 

• ріпд — команда отправки и получения пакетов ІСМР ( ЕсіюНедиезі / 
Есію Реріу)-, 

• и /ііоаті — команда получения имени текущей учётной записи; 

• ззіі — команда подключения к серверу 35/-/;* іі сіоѵѵп — команда 

отключения сетевого интерфейса; 

• Пир — команда включения сетевого интерфейса; 

• зегѵісе — команда управления сервисами; 

• ііу-асітіп-ѵѵіссі — графическая утилита «Сетевые подключения» для 
управления параметрами сетевого интерфейса; 

• Пу-адтіп-сіеѵісе-тападег — графическая утилита «Менеджер 
устройств» для управления параметрами устройств, в том числе 
сетевых интерфейсов. 



Используемое методическое и лабораторное обеспечение 

1. Три компьютера (либо виртуальные машины) с ОССН версии 1.6, соединённые в сеть 
последовательно: АзігаСІіепіІ, Азіга-Ноиіег, АзігаСИепі2. При этом компьютер с ОССН 
АзігаНоиіег два сетевых интерфейса, соединённых с ОССН АзІгаСІіепІІ и АзІгаСІіеп12: 
АзІгаСІіепІІ (еШО) — {еІНСО) АзігаНоиіег (еІЫ) -(еІІЮ) АзІгаСІіеп12 . 

2 . В каждой ОССН создана учётная запись пользователя изег, с параметрами: 
максимальный и минимальный уровни доступа — 0, неиерархические категории — нет, 
уровень целостности — «Высокий», входит в группу администраторов — азігаасітіп 
(вторичная группа), разрешено выполнение привилегированных команд ( зидо). 

3. Дистрибутив ОССН. 

4 . Документация: «Операционная система специального назначения «Азіга Ипих ЗресіаІ 
Есііііоп». Описание применения», «Операционная система специального назначения «Азіга 
Стих ЗресіаІ Есііііоп». Руководство администратора. Часть 1», «Операционная система 
специального назначения «.Азіга Ипих ЗресіаІ Есііііоп». Руководство по КСЗ. Часть 1». 

5 . Для выполнения работы в течение двух занятий необходимо обеспечить возможность 
сохранения состояния ОССН за счёт применения технологий виртуализации (создания 
виртуальных машин ОССН). 

Порядок выполнения работы 

1. Начать работу с входа в ОССН АзігаСІіепіІ , АзігаСІіепі2 и АзігаНоиіег в графическом 
режиме с учётной записью пользователя изег (уровень доступа — 0, неиерархические 
категории — нет, уровень целостности — «Высокий»), 

2. В ОССН АзігаСІіепіІ, АзігаСІіепі2 и АзігаНоиіег запустить терминал ЕІу в 
«привилегированном» режиме командой зисіоііу-іегт, и вывести информацию о доступных 
сетевых интерфейсах командой ір Ііпк Іізі. 

3. Настроить ОССН АзігаСІіепіІ . Для этого выполнить следующую последовательность 
действий: 

• настроить параметры сетевого интерфейса еіЫО командой ірасісігезз адд 
10.0.0.2/8 сіеѵеіііІЗ ; 

• настроить маршрутизацию в подсеть 20.0.0.0/8 командой іргоиіе асісі 
20.0.0.0/8 ѵіа 10.0.0.1; 

• вывести таблицу маршрутизации командами ір гоиіе и гоиіе, убедиться в 
добавлении маршрута в подсеть 20.0.0.0/8; 

• проверить установку сервера ЗЗН командой арі-деі іпзіаііорепззіі-зегѵег 
(здесь и далее при выполнении команды арі-деіпотребуется установка 
О ѴО с дистрибутивом ОССН); 

а выполнить запуск сервера командой зегѵісе ззіі зіагі. 



4. Выполнить настройки сетевого интерфейса ОССН АзігаСІІепіІ . Для этого выполнить 
следующую последовательность действий: 

• настроить параметры сетевого интерфейса еіііО командой Нсоп-іід еіПО 
20.0.0.2 пеітазк 255.0.0.0 Ьгоасісазі 20.0.0.255; 

• настроить маршрутизацию в подсеть 10.0.0.0/8 командой гоиіеасісі -пеі 
10.0.0.0/8 дѵѵ 20.0.0.1; 

• вывести таблицу маршрутизации командами гоиіе -п и ір гоиіе, 
убедиться в добавлении маршрута в подсеть 10.0.0.0/8. 

5. В ОССН АзігаНоиіег выполнить настройку статических сетевых адресов и 
маршрутизации. Для этого выполнить следующую последовательность действий: 

• используя редактирование файла / еіс/пеіѵѵогк/іпіегіасез командой ѵіт / 
е Іс/пеіѵ/огк/іпіегіасез (файл / еіс/ пеіѵѵогк/іпіег-іасез должен содержать 
следующие строки настройки: «аиіоеіІіО», «Пасе еіі)0 іпеі зіаііс», 
«асісігезз 10.0.0.1», «пеітазк 255.0.0.0», «аиіо еіііі», «Пасе еіііі іпеі 
зіаііс», «асісігезз 20.0.0.1», «пеітазк 255.0.0.0»), настроить адреса 
сетевых интерфейсов; 

• выполнить перезагрузку и повторный вход в ОССН АзігаНоиіег с учётной 
записью пользователя изег (уровень доступа — 0, неиерархические 
категории — нет, уровень целостности — «Высокий»); 

• запустить терминал Р/у и проверить доступность АзігаСІІепіІ , 
АзігаСІіепі2 с АзігаНоиіег по сети, выполнив для этого команды ріпд 
20.0.0.2, ріпд 10.0.0.2; 

• запустить терминал Р/у в «привилегированном» режиме командой зисіо 
ііу-іегт; 

• включить функцию «ІР іогѵѵагсЧпд» командой зузсіі -ѵѵ пеі.ірѵі Ар-іотагсІ 
-1; 

• выполнить команду ѵіт /еіс/зузсіі. сопі и раскомментировать параметр 
пеі.ірѵ4-ір-іогѵѵагсІ = 1 в конфигурационном файле/ еіс/зузсіі. сопі; 

• установить пакет еііііооі командой арі-деі іпзіаІІ еііііооі. 

6. Проверить функционирование маршрутизации между подсетями 10.0.0.0/8 и 20.0.0.0/8. 
Для этого выполнить следующую последовательность действий: 

• в ОССН АзігаСІІепіІ выполнить команду ріпд 20.0.0.2; 

• в ОССН АзігаСІіепі2 выполнить команду ріпд 10.0.0.2. 

7. В ОССН АзігаСІІепіІ проверить работоспособность сервера 88Н путём проверки 
открытого им порта командой 55 -Ір. Определить номер порта, который прослушивает сервер 
ззкісі. 



8. Работая в ОССН А8ігаСІіепі2, выполнить подключение с учётной записью 
пользователя изег к серверу 88Н, установленному на ОССН АзігаСІІепіІ . Для этого 
выполнить следующую последовательность действий: 

• запустить терминал Р/у в «привилегированном» режиме командой зидо 
ііу-іегт] 

• выполнить команду ззіі -I изег 10.0.0.2 и ввести пароль учётной записи 
пользователя изег в ОССН АзігаСІІепіІ ; 

• убедиться в работоспособности сетевого соединения с помощью 
удалённого доступа по протоколу 88Н, выполнив идентификацию 
пользователя изег командой ѵѵііоаті и просмотр содержимого его 
домашнего каталога командой Із -аІ\ 

• проверить наличие соединения ОССН АзігаСІІепіІ с ОССН АзігаСІіепі2 
(ІР-адрес 20.0.0.2) по порту ззіі командой 55 -іа\ 

завершить удалённую сессию командой ехіі; 

• вывести информацию о МЛ С-адресах в ОССН АзігаСІіепі2 с 
использованием команд агр и саі /ргос/пеі/агр, а затем сравнить 
полученные результаты. 

9. В ОССН АзігаНоиіег выполнить команды управления сетевыми интерфейсами. Для 
этого реализовать следующую последовательность действий: 

• запустить терминал Р/у в «привилегированном» режиме командой зидо 
ііу-іегт ; 

• определить скорости работы сетевых интерфейсов еіііО и 

е//і /командами тіі-іооі еіііО и тіі-іооі еіііі; 

• снизить скорость сетевого интерфейса еіііО до 100 Мбит/с (либоЮ 
Мбит/с в зависимости от текущей скорости сетевого интерфейса) в 
режиме Наіі йиріех командой тіі-іооі еіііО -Р ЮО-ВазеТх-ПЗ и убедиться 
в применении изменений командой тіі-іооі еіііО. 

ю. Выполнить настройки сетевых интерфейсов в ОССН Азіга-СІіепіІ с использованием 
графической утилиты «Сетевые соединения». Для этого выполнить следующую 
последовательность действий: 

• выполнить перезагрузку и повторный вход в ОССН АзігаСІІепіІ с 

учётной записью пользователя изег (уровень доступа — 0, 

неиерархические категории — нет, уровень целостности — «Высокий»); 

• запустить терминал Р/у в «привилегированном» режиме командой зидо 
ііу-іегт и проверить отсутствие ІР-адреса интерфейса еіііі командой 
іісопіід; 



• в графической утилите «Сетевые соединения» выбрать режим 
«Использовать статические /Р-адреса» и ввести следующие параметры: 
«1Р-адрес» — 10.0.0.2, «Маска сети» — 255.0.0.0, «Основной шлюз» — 
10.0.0.1; осуществить подключение к сети; 

• проверить корректность установки параметров сетевого интерфейса 
еіііО командой іісопіід, а затем проверить корректность установки 
маршрута по умолчанию командой гоиіе\ проверить доступность 
АзігаСІіепіІ , выполнив команду р/лс/20.0.0.2; 

• выполнить отключение сетевого интерфейса еіііО в графической 
утилите «Сетевые соединения» и проверить результат командой 
іісопіід: 

• выполнить включение сетевого интерфейса еіііО в графической утилите 
«Сетевые соединения» и проверить установку ^-адреса 10.0.0.2 
командой іісопіід. 

11. Проверить совместную работу приложений конфигурирования сетевых интерфейсов в 
ОССН АзігаСІіепіІ . Для этого выполнить следующую последовательность действий: 



• сконфигурировать статический сетевой адрес, используя настройки 
графического менеджера аналогичные настройкам файла / еіс/ 
пеіѵѵогк/іпіегіасез (файл / еіс/пеіѵѵогк/іпіегіасез содержит следующие 
строки: «аиіо еіііО», «Пасе еіііО іпеі зіа-ііс», «асісігезз 10.0.0.3», 
«пеітазк255.0.0.0», «даіеѵѵау 10.0.0.10»): 


МсіЬосІ Вручную 

Адреса 

Адрес Масса спи Шякп 

10 0 0 і 8 10 0.010 


« найти в каталоге / еіс/Меіѵѵогк Мападег файлы с сохранёнными настройками, которые были 
сделаны на предыдущем этапе. 

іі. Настроить ОЛ/3- сервер для организации следующей адресации и именования 
компьютеров: АзігаНоиіег (еіііО) — 192.168. 1 .Згоиіег.аѵѵ.ги, АзігаСІіепіІ — 192.168.1.10 





зіаііопі.аѵѵ.ги. Для этого выполнить следующую последовательность действий в ОССН 
АзІгаНоиІег. 


• запустить терминал Ну в «привилегированном» режиме; 
сконфигурировать статический сетевой адрес, используя настройки графического менеджера 
аналогичные настройкам файла / еіс/ пеіѵѵогк/ іпіегіасез (файл / еіс/ пеіѵѵогк/ іпіегіасез 
содержит следующие строки: «аиіо еІІіО», «Пасе еіЮ іпеі зіа-ііс», «асісігезз 192.168.1.3», 
«пеітазк 255.255.255.0», «да^еи/ау192.168.1.1»); 

• выполнить установку службы ОЛ/3-сервера командой арі-деііпзіаіі ЫпсІ/; 

• создать файл ІеІс/Ыпсі/сІЬ.аѵѵ.ги командой тсесііі /еІс/Ьіпсі/сІЬ.аѵѵ.ги со 
следующим содержимым: 



$тп 30 

$0К1 Б IН аш.ги. 


В ІН БОН аы.ги. агітіп.аи.гіі. ( 
:2018110201; 

<-> 10 ; 

< ->1Ь; 

< ->1и; 

< - :2Ь; 

) 

В III N5 аи.ги. 

В ІН Н 192.168.1.3 


гоиіег ІН Н 192.168.1.3 
зіаііопі ІН Н 192.168.1.10 


• создать файл Іеіс/ЬіпсІА .168.192. іп-аддг.агра.гопе командой тсесііі 
/еІс/ЫпсІ/І. 168.192 . 'т-аМг.агра.гопе со следующим содержимым 


[7еі;с/Ьіпсі/1:. 16В.І^іп-аёісіг.агра. гопе .Гг;*-- 3■ ■ .-0 :Ш ’і-1'ФІ5' 


1,168.192 іп-асісіг.ѳгра. 10800 ІИ ЗОН аи.ги. айлііп.аи.ги. ( 
> 2010110201 ; 

< —> 10 ; 

< >1Ь; 

<- —>1и; 

< ->2Н; 

) 

115 аи.ги. 

3 РТР аи.ги. 

3 РТР гоиіег.аи.ги. 

10 РТР зіаііопі.аи.ги. 


отредактировать файл / еІс/ЬЫ/ патед.сопі.іосаі командой тсесііі 
/еІс/ЬіпсІ/патесІ.сопі.ІосаІ, добавив следующее содержимое: 


13 . 


Настроить параметры сетевых интерфейсов 


опе "аи.ги" { 

Іуре шазіег; 

Піе "/еІс/Ыпгі/0Ь.аи.ги"; 


ОССН АзІга-СІіепІІ для работы с ОЛ/5-сервером. Для гопе "1.160.192.іп-асШг.агра" 1 

іуре ілазіег; 

Ті Іе "/еІс/Ыпсі/1.168.192. Іп-асШг.агра. гопе" 








этого выполнить следующую последовательность действий: 

• в графической утилите «Сетевые соединения» ввести следующие 
параметры: «1Р-адрес» — 192.168.1.10, «Маска сети» —255.255.255.0, 
«Основной шлюз» — 192.168.1.3, «ОЛ/5-домен» — аѵѵ.ги, «Поиск в 
домене» — аѵѵ.ги, «ОТѴЗ-сервер» — 192.168.1.3; 

• выполнить перезагрузку и повторный вход в ОССН АзігаСІіепіІ и 
АзігаНоиіег с учётной записью пользователя изег (уровень доступа — 0, 
неиерархические категории — нет, уровень целостности — «Высокий»); 

• запустить терминал Р/у и проверить корректность функционирования 
ОЛ/5-сервера командами ріпд зіаііопі.аѵѵ.ги и ріпд гоиіег, аѵѵ.ги-, 

• создать в ОССН АзігаСІіепіІ учётную запись пользователя іезі, 
включить его в группу азіга-сопзоіе; 

• запустить терминал Р/у в «привилегированном» режиме командой зидо 
Ну-іегт и изменить максимальный мандатный уровень доступа учётной 
записи Іезі командой рсірі-изег-т 0:2 іезі ; 

• выполнить выход и повторный вход в ОССН АзігаСІіепіІ с учётной 
записью пользователя іезі (уровень доступа — 2, неиерархические 
категории — нет, уровень целостности — «Низкий»); 

• запустить терминал Р/у и осуществить попытку проверки 
функционирования РІѴЗ-сервера командами ріпд зіаііопі.аѵѵ.ги ѵ\ріпд 
гоиіег.аѵѵ.ги, проанализировать ошибки. 

14. Настроить ОЛ/5-сервер в ОССН АзігаНоиіег для работы с использованием механизма 
ргіѵзоск. Для этого выполнить следующую последовательность действий: 

• запустить терминал Р/у в «привилегированном» режиме командой зидо 
Ну-іегт\ 

• изменить файл / еіс/рагзес/ргіѵзоск.сопі, добавив в него строку (перед 
этим проверить, что файл /еіс/рагзес/ргіѵзоск.сопі оканчивается пустой 
строкой), содержащую / изг/зіііп/патесіюмандоіл есііо «.Іизг/зЫп/патесі» 
» /еіс/рагзес/ргіѵзоск.сопі; 

• проверить внесённые изменения командой саі / еіс/рагзес/ргіѵ-зоск. 
сопі; 

• изменить настройки ОЛ/5- сервера в файле / еіс/ сіеіаиІі/ЫпсІз командой 
есііо «РАТН=/изг/ІіЬ/рагзес/Ып:\$РАТН» » /еіс/сіеіаиіі/ЬЫ9; 

• перезапустить ОЛ/5-сервер командой зегѵісе Ыпсі9 гезіагі. 




15 . Проверить работу ОССН АзігаСІіепіі с ОЛ/5-сервером в сессии, функционирующей от 
имени учётной записи пользователя іезіс мандатным уровнем доступа равным 2. Для этого 
выполнить следующую последовательность действий: 

• запустить терминал Ну и проверить распознавание сетевого имени 
ОССН АзігаСІіепіі командой ріпд зіаііопі.аѵѵ.ги; 

• выполнить команду проверки доступности ОЛ/5-сервера ріпдгоиіег, аил 
ги. 

Содержание отчёта по выполненной работе 
В отчёте о выполненной работе необходимо указать: 

1. Полный перечень использованных команд с описанием их назначения. 

2 . Примеры выполнения команд, которые были использованы в ходе работы с описанием 
результатов их выполнения. 

3. Описание порядка работы с графической утилитой пт-арріеіп ри настройке параметров 
проводных и беспроводных сетевых интерфейсов. 

4. Описание порядка работы с командами при выполнении следующих операций: 

• настройка адресации сетевого интерфейса; 

• настройка статической маршрутизации; 

• проверка настроенных параметров сетевого интерфейса и таблицы 
маршрутизации; 

• проверка достижимости удалённых сетей;» настройка механизма 
ргіѵзоск. 

Контрольные вопросы 

• Каково назначение пакета іргоиіеіі 

• Какие основные команды реализуются пакетом іргоиіе2? 

• Какие отличительные особенности пакетов іргоиіе 2 и пеі-іооіз ? 

• Какими командами пакетов іргоиіеі и пеі-іооіз задаются параметры сетевого 
интерфейса (ІР-адрес, маска сети)? 

• Какими командами пакетов іргоиіе и пеі-іооіз задаётся добавление статического 
маршрута? 

• Каково назначение конфигурационных файлов в каталоге I еіс/Меіѵѵогк-Мападег? 

• Какие параметры ядра обеспечивают включение функции «ІР іогѵѵагсІ-іпдѵ> ? 

• Какими командами осуществляется проверка и управление характеристиками сетевых 
интерфейсов? 

•Какие особенности настройки работы сетевых служб с использование механизма 
ргіѵзоск ? 



4. 7. Лабораторная работа № 7. 

Конфигурирование службы Азіга Ыгшх йігесіогу 

Цель работы 

Получить практический опыт установки и настройки параметров службы Азіга ііпих йігесіогу 
(АШ) в ОССН. 

Время выполнения работы 6 академических часов. 

Краткие теоретические сведения 

В компьютерных сетях, построенных на основе ОССН, имеется возможность 
организовать централизованное хранение учётных записей пользователей в домене АІО 
(далее — домене), а также развёртывать централизованный защищённый файловый сервер, 
содержащий сетевые домашние каталоги данных учётных записей пользователей. Таким 
образом, у учётных записей пользователей АІО появляется возможность регистрации и 
доступа к своим сетевым объектам с любого компьютера, входящего в домен. Это особенно 
актуально, в случае территориальной удалённости между контроллером АШ и 
компьютерами, входящими в состав домена. 

Хотя в ОССН версии 1.6 также реализована более современная доменная инфраструктура 
РгееІРА, которая подробно рассмотрена в главах 1 и 3, её конфигурирование и настройка 
являются гораздо более сложными, чем АІО, и поэтому выходят за рамки лабораторной 
работы. 

Администратор домена АІО выполняет следующие функции по управлению доменом: 

•централизованное управление учётными записями пользователей домена с 
использованием команды аісі-асітіп и графической утилиты «Политика безопасности» 
(для этого необходимо установить расширение зтоіепзк-зесигііу-аісі) ; 

•настройка СЗИ, управляющих их доступом к файловым сущностям защищённого 
файлового сервера. 

Централизованная база данных учётных записей пользователей домена (ОІВ — Оотаіп 
Іпіогтаііоп Вазе) создаётся на основе службы ШАР (ИдЫѵѵеідЫ Оігесіогу Ассезз Ргоіосоі), 
обеспечивающей как организацию хранилища учётных записей пользователей АІО, так и 
процедуру аутентификации пользователей на компьютере с использованием АІО. 
Безопасность процедуры аутентификации пользователей домена обеспечивается 
применением протокола доверенной аутентификации КегЬегоз. Для синхронизации 
временнных меток при взаимодействии контроллера и клиентов КегЬегоз используется 
протокол /ѴТР (Меіѵѵогк Тіте Ргоіосоі). 

При доступе к сущностям файловой системы компьютера, с которого осуществлён вход в 
домен с некоторой учётной записью пользователя, для неё применяются настройки 
управления доступом, хранящиеся на контроллере АІО. Если же на контроллере АІО (или 



на специально выделенном компьютере) организуется защищённый файловый сервер, то 
настройки управления доступом для этой учётной записи пользователя применяются также к 
сущностям файловой системы этого контроллера. При этом доступ к ним от имени учётной 
записи пользователя АІО осуществляется по протоколу СІРЗ (Соттоп Іпіегпеі Р/Ѵе Зузіет), 
являющемуся развитием протокола сетевого файлового обмена ЗМВ. 

Служба АІО обладает расширяемой архитектурой, состоящей из ядра, отвечающего за 
основной функционал системы, ряда интерфейсов (ШАР, КегЬегоз) и модулей расширения, 
команд и графических утилит настройки служб и подсистем АІО, что позволяет расширять 
функциональность АІО, устанавливая дополнительные пакеты. Основные пакеты, 
используемые при установке и настройке АІО: 

•аід-сііепі-соттоп — клиентская часть АІО (можно также использовать метапакет аід- 
сііепі); 

•аісі-асітіп — команды администрирования АІО; 

• аісі-зегѵег-соттоп — серверная часть АІО (можно также использовать метапакет аід- 

зегѵег); 

•зтоіепзк-зесигііу-аід —расширения графической утилиты «Политика безопасности», 
позволяющие осуществлять управление доменом (можно также использовать 
метапакеты аісі-асітіп- аісі-зе или аісі-асітіп-аісі-зегѵег). 

На компьютере, осуществляющем функции контроллера АІО, операции по 
администрированию АІО выполняются от имени учётных записей пользователей, 
обладающих соответствующими административными полномочиями. В зависимости от 
назначенных привилегий администраторов АІО можно разделить на следующие группы по 
полномочиям: 

•корневой администратор (имя адтіп/ адтіп, администратор АІО) — обладает всеми 
полномочиями по управлению доменом; 

•администраторы (пользователи с привилегией адтіп) — обладают полномочиями по 
управлению конфигурацией домена и учётными записями пользователей; 

•ограниченные администраторы (учётные записи пользователей с привилегиями ііозіз- 
адд или аід-ііозіз-адд) — обладают полномочиями по добавлению компьютеров в 
домен; 

• пользователи утилит администрирования (пользователи с привилегией адт-изег) — 

обладают полномочиями по запуску утилит администрирования; 

•обычные пользователи. 

Для администрирования домена используются команды аісі-асітіп и графическая утилита 
«Политика безопасности», которая позволяет выполнять следующие действия с доменом: 

•создание и администрирование учётных записей пользователей 



•создание и администрирование групп; 

•добавление и удаление компьютеров; 

•резервирование и восстановление учётной информации баз данных домена; 
•конфигурирование привилегий и политик СЗИ для учётных записей пользователей и 
групп; 

•конфигурирование политик паролей КегЬегоз; 

•администрирование доступа к съёмным устройствам; 

•администрирование учётных записей сетевых служб (сервисов); 

•контроль целостности (аудит) конфигурации домена. 

При создании нового домена используется следующая последовательность действий: 

•настройка сетевого соединения на контроллере АІО и компьютерах, которые будут 
включены в АІО; 

•настройка именования контроллера и клиентов АІО для поддержки функционирования 
службы ІО АР; 

•конфигурирование и запуск контроллера АІО; 

•запуск клиентов АІО на компьютерах, входящих в АІО. 

Данная последовательность действий рассматривается при выполнении лабораторной 
работы. 

При развёртывании средств обеспечения единого пространства пользователей с 
применением АІО используются следующие команды (примеры применения которых также 
рассмотрены в главе 3): 

• ііозіпате — команда вывода в терминал текущего имени компьютера; 

•арі-деі — команда управления пакетами; 

•ріпд — команда отправки и получения пакетов ІСМР (Есііо Педиезі/ Есііо Реріу); 

• аісі-іпіі — команда инициализации базы данных АІО; 

•аісі-сііепі — команда управления клиентом АІО; 

•аісі-асітіп — команда управления доменом АІО. 

Используемое методическое и лабораторное обеспечение 

1. Три компьютера с ОССН версии 1. 6, объединённые в сеть. Первый предназначен для 

использования в качестве контроллера АІО — далее обозначается АзІгаЗегѵег; 
остальные — компьютеры, подключаемые в домен (АзігаСІІепіІ , Аз1гаСІіеп12). В ОССН 
настроена синхронизация времени с использованием протокола Л/7Р, либо, при 
использовании виртуальных машин временные метки считываются автоматически из 
единого системного времени. 

2. В каждой ОССН создана учётная запись пользователя изег, с параметрами: максимальный 

и минимальный уровни доступа — О, неиерархические категории — нет, уровень 



целостности — «Высокий», входит в группу администраторов — азіга-адтіп (вторичная 
группа), разрешено выполнение привилегированных команд (зисіо). 

З.Дистрибутив ОССН. 

^Документация: «Операционная система специального назначения «Азіга Ипих 8ресіаІ 
Есііііоп». Руководство администратора. Часть 1», «Операционная система специального 
назначения «Азіга Ипих 8ресіаІ Есііііоп». Руководство по КСЗ. Часть 1». 

б.Для выполнения работы в течение двух занятий необходимо обеспечить возможность 
сохранения состояния ОССН за счёт применения технологий виртуализации (создания 
виртуальных машин с ОССН). 

Порядок выполнения работы 

1 .Для настройки сетевого соединения на контроллере и клиентах Айй начать работу со 
входа в ОССН АзігаСІІепѴ\ , АзігаСІІеп12 и АзігаЗегѵег в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»), 

2. В ОССН АзігаСІіепіІ , АзігаСІіепі2 и АзігаЗегѵег выполнить настройку статических 
сетевых адресов 10. 0. 0. Х/8, где сетевые адреса «10. 0. 0. X» задаются в соответствии со 
следующим списком: для АзігаЗегѵег — 10. 0. 0. 10, для АзігаСІіепі 1 — 10. 0. 0. 1, для АзігаСііепі2 
— 10 . 0 . 0 . 2 . 

3. Выполнить перезагрузку и повторный вход в каждую ОССН с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»), затем запустить терминал ЕІу. 

4. Выполнить проверку корректности настроек командой ріпд. При этом проверить 
доступность АзігаСІіепіІ , АзігаСІіепі2 с АзігаЗегѵег по сети командами: ріпд 10. 0. 0. 1 и ріпд 10. 
0. 0. 2. Затем проверить доступность АзігаСІіепіІ с АзігаСііепі2 командой ріпд 10. 0. 0. 1. 

5. Выполнить настройку имени контроллера и клиентов АйО для поддержки 
функционирования службы йОАР. Для этого необходимо, чтобы разрешение сетевых имён было 
настроено таким образом, чтобы сетевое имя компьютеров разрешалось, в первую очередь, как 
полное имя (например, азіга-зегѵег. ехатріе. ги). При этом команда ііозіпате должна возвращать 
короткое сетевое имя (например, азіга-зегѵег цпя АзігаЗегѵег). Для этого выполнить следующую 
последовательность действий: 

• в ОССН АзігаЗегѵег в «привилегированном» режиме терминала ЕІу выполнить команду 
ѵіт/еіс/іюзіпате и сделать запись «. азіга-зегѵег», а в ОССН АзігаСІіепіІ и АзігаСІіепі2 
— «азіга- сііепіі» и «азіга-сііеп12» соответственно; 

•в ОССН АзігаЗегѵег, АзігаСІіепіІ и АзігаСІІепі2 в «привилегированном» режиме 
терминала ЕІу выполнить команду ѵіт/еіс/Іюзіз и добавить следующие строки: «10. 0. 
0. 10 азіга-зегѵег. ехатріе. ги азіга-зегѵег», «10. 0. 0. 1 азіга-сііепіі . ехатріе. ги азіга- 



сііепі 1», «10. 0. 0. 2 азіга-сІіеп12. ехатріе. ги азіга-сІіеп12», и закомментировать строку, 
содержащую запись «127. 0. 1. 1» (для этого поставить в начале данной строки «#»): 


бНІГ.пало 2.1 А : ■ ." ТУТ .Ша&'л: УеТс/Ног-ІБІ 


127.0.0.1 1 оса 1Нозі 

0127.0.1.1 азіга 

10.0.0.10 азіга-зегѵег.ехатріе.ги азіга-зегѵег 

10.0,0,1 азіга-сііепіі.ехатріе.ги а5Іга-с1іепіі 

10,0,0,2 азіга-сіІеп12.ехатріе.ги азіга-сііепі2 

•выполнить перезагрузку ОССН АзігаЗегѵег, АзігаСІіепіІ, АзігаСІіепі2 и войти в ОССН 
АзігаСІіепіІ, АзігаСІІепі2 и АзігаЗегѵег в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»); 

•в каждой ОССН запустить терминал Ну, выполнить команду ііозіпате и проверить, что 
она возвращает короткие имена «азіга-зегѵег», «азіга-сІіепі\» и «азіга-сІіеп12» для 
ОССН АзігаЗегѵег, АзігаСІіепіІ и АзігаСІіепі2 соответственно: 
гоо1@аз1га-зегѵег:/Ьоте/изег# Ьозіпате 

азіга-зегѵег 

•проверить доступность АзігаЗегѵег с АзігаСІІепП, АзігаСІіепіІ2 по сети с использованием 
имени, выполнив для этого команды ріпд азіга-зегѵег и ріпд азіга-зегѵег. ехатріе. ги в 
ОССН АзігаСІіепіІ и АзігаСІіеп12; 

•проверить доступность АзігаСІіепіІ, АзігаСІіепі2 с АзігаЗегѵег по сети с использованием 
имени, выполнив для этого команды ріпд азіга-сііепі, ріпд азіга-сііепі2, ріпд азіга-сііепП. 
ехатріе. ги ріпд азіга-сііепі2. ехатріе. ги в ОССН АзігаЗегѵег. 

6.Выполнить установку, конфигурирование и запуск контроллера. Для этого реализовать 
следующую последовательность действий в ОССН АзігаЗегѵег: 

•войти в графическом режиме с учётной записью пользователя изег (уровень доступа — 
0, неиерархические категории — нет, уровень целостности — «Высокий»); 

•запустить терминал Ну в «привилегированном» режиме командой зисіо ііу-іегт; 

•выполнить установку пакетов для работы с контроллером командой арі-деі іпзіаіі аісі- 
зегѵег-соттоп (здесь и далее при выполнении команды арі-деі потребуется установка 
йѴй с дистрибутивом ОССН); 

•выполнить команду ѵіт/еіс) аісі/аісі. сопі и проверить наличие параметров 
«8ЕКѴЕК=азігазегѵег. ехатріе. ги» и «ООШ/Л/ =. ехатріе. ги»: 

ООМАІМ=. ехатріе. сот 

# ТНе пате о! уоиг сіотаіп (аізо изесі аз КегЬегоз геаіт іп иррег-сазе). 

# ЗНоиІсІ Ье іп ІМе Іогт: 

#. ехатріе. сот 

# ІІЧОТЕ! (Іог аісі-зегѵег). II ІМз ѵаіие із сИапдесІ - ІМе зегѵег зИоиІсІ Ье геіпіііаіігесі Ьу: 


# $ аісі-іпіі ігііі 

# Ог уои зЬоиІсІ изе 1Ье соттапсіз 'аісі-іпіі Ьаскир-ІсІіГ апсі 

# 'аісі-іпіі гезІоге-Ьаскир-ІсІіГ. 

ЗЕВѴЕВ=азІга-зегѵег. ехатріе. сот 

# РиІІу диаіійесі пате Азіга І_іпих йігесіогу зегѵег. 

# ЗЬоиІсІ Ье іп 1Ье Іогт: 

# ту-аісі-зегѵег. ехатріе. сот 

•для того чтобы служба АЬО заново считала изменения в файле /еІс/аІЬ,/аІЬ. сопі 
(если они реально делались, иначе пропустить указанную далее команду) 
выполнить инициализацию командой аісі-іпіі соттіі-сопіід (результатом будет 
информация об успешном конфигурировании службы АЬО); 

• выполнить команду инициализации аід-іпіі іпіі и по требованию этой команды 
подтвердить повторную инициализацию баз данных І-ОАР и КегЬегоз, ввести и 
подтвердить новый КегЬегоз- пароль «кегЬегозгооі», ввести и подтвердить новый 
пароль администратора АЬО «аісі-гооі»: 

ВНИМАНИЕ! Команда 'іпіГ УНИЧТОЖИТ ВСЮ БАЗУ ДАННЫХ ЬйАР и КегЬегоз! 

Также Во Время Выполнения этой команды могут быть остановлены и перезапущены 
1_0АР, КегЬегоз, МР5/5атЬа и некоторые другие службы. 

Разыменованное имя компьютера: азіга-зегѵег. ехатріе. сот 

Контроллер домена '. ехатріе. сот' будет создан со следующими параметрами: 

Сервер: азіга-зегѵег. ехатріе. сот 

Роль сервера: Первичный контроллер домена 

Ю сервера:1 

Первичный контроллер домена: азіга-зегѵег. ехатріе. сот 
Вы УВЕРЕНЫ, что хотите ВЫПОЛНИТЬ эту операцию? (уез/по) [по]: уез 
Введите новый главный пароль к базе данных КегЬегоз (НЕ ЗАБУДЬТЕ ЕГО!): **** ******** 
Повторите пароль: ************ 

Введите новый пароль администратора Азіга Ыпих Оігесіогу (НЕ ЗАБУДЬТЕ ЕГО!): ******* 
Повторите пароль: ******* 

Сохранение конфигурации. . . 

Остановка сервиса зтЬб. . . 

Остановка сервиса птЬб. . . 

Обработка конфигурационного файла '/еіс/ехроііз'. . . 

Переименование Ѵеіс/ехрогіз. Ітр' в '/еіс/ехрогіз'. . . 

Запуск сервиса птЬб. . . 

Запуск сервиса зтЬб. . . 



Перезапуск сервиса пзссі. . . 

Перезапуск сервиса пзіссі. . . 

Перезапуск сервиса аісісі. . . 

Азіга І_іпих Рігесіогу сконфигурирована. 

Сервер АШ активен. 

Клиент АЮ Включен. 

Азіга І_іпих Оігесіогу сервер успешно инициализирован. 

7.Выполнить установку, конфигурирование, запуск клиентов АІО. Для этого реализовать 
следующую последовательность действий: 

• в ОССН АзігаСіІепіІ запустить терминал Р/у в «привилегированном» режиме командой 

зисіо ііу-іегт; 

•выполнить установку пакета аісі-сііепі- соттоп командой арі- деі іпзіаІІ аісі-сііепі-соттоп; 

• выполнить команду папо/еіс/аісі/аісі. сопі и отредактировать следующие параметры: 

«ЗЕОѴЕО = азіга-зегѵег. ехатріе. ги» и «ООМА/Л/ =. ехатріе. ги»; 

• выполнить инициализацию настроек и подключение к контроллеру командой аісі-сііепі 

соттіі-сопіід; 

• в качестве имени учётной записи пользователя администратора ввести пробел или 

асітіп/ асітіп, далее ввести пароль администратора АІО аісі-гооі; 

• выполнить запуск клиента АІО командами аісі-сііепі зіагі (для включения компьютера в 

домен может отдельно использоваться команда аісі-сііепі]ОІп). 

8.Осуществить проверку функционирования и настройку контроллера и клиентов АІО. Для 
этого выполнить следующую последовательность действий: 

• в ОССН АзігаЗегѵег выполнить установку расширения графической утилиты 

«Управление политикой безопасности», используемого для конфигурирования 
контроллера АІО командой арі-деі іпзіаІІ зтоіепзк-зесигііу-аісі; 

•запустить графическую утилиту «Политика безопасности» через меню «Панель 
управления» главного пользовательского меню и открыть вкладку «Домен АІО», 
соответствующую настройкам созданного домена; 

•для администрирования домена необходимо выполнить подключение, проверить имя 
пользователя «асітіп/ асітіп», ввести пароль администратора АІО «аісі-гооі», а затем 
проверить, что контроллер АІО активирован (при этом должна отображаться надпись 
«Сервер домена: азіга-зегѵег. ехатріе. ги»); 

•в дереве элементов вкладки политик безопасности контроллера азіга-зегѵег. ехатріе. ги 
выбрать узел «Компьютеры» и проверить, что в состав домена с именем «. ехатріе. 
ги» входят контроллер АІО «азіга-зегѵег. ехатріе. ги» и клиент «азіга-сііепіі . ехатріе. 
ги»; 



9. Создать новую учётную запись пользователя АІО и осуществить вход с ней в ОССН 
АзІгаСІіепІ. Для этого осуществить следующие действия: 

•в ОССН АзІгаЗегѵег запустить графическую утилиту «Политика безопасности» через 
меню «Панель управления» главного пользовательского меню и открыть вкладку 
«Домен АІ_Э» в разделе «Элементы»; 

•осуществить подключение с учётной записью пользователя « асітіп/асітіп»; 

•в дереве элементов вкладки политик безопасности контроллера азіга-зегѵег. ехатріе. ги 
выбрать узел «Пользователи» и создать новую учётную запись пользователя изегаісі, 
при этом задав её пароль (обратить внимание на требование политики по сложности 
пароля); 

•в учётной записи пользователя изегаісі в вкладке «Привилегии домена» выбрать 
«Компьютеры» добавить только азіга-зегѵег. ехатріе. ги и применить изменения; 

•в ОССН АзігаСІіепі 1, АзІгаСІіеп12 выйти из ОССН; 

•осуществить попытку входа в ОССН АзігаСІіепі с новой учётной записью пользователя 
изегаісі и проанализировать выводимые ошибки; 

•теперь в учётной записи пользователя изегаісі в вкладке «Привилегии домена» выбрать 
«Компьютеры» и добавить азіга-сііепі 1 . ехатріе. ги; 

•войти в ОССН АзІгаСІіепІІ с учётной записью пользователя изегаісі; 

•осуществить попытку входа в ОССН АзІгаСІІеп12 с учётной записью пользователя изегаісі 
и проанализировать выводимую ошибку. 

10.Осуществить установку, конфигурирование, запуск клиента АІО на АзігаСІіепі. Для 
этого выполнить следующую последовательность действий: 

•войти в ОССН АзІгаСІІеп12 в графическом режиме с учётной записью пользователя изег 
(уровень доступа — 0, неиерархические категории — нет, уровень целостности — 
«Высокий»); 

•запустить терминал Ну в «привилегированном» режиме командой зисіо ііу-іегт; 
•выполнить установку пакета аісі-сііепі-соттоп командой арі деі іпзіаіі аісі-сііепі-соттоп; 
•выполнить подключение к домену командой аісі-сііепііоіп азіга-зегѵег. ехатріе. ги; 

• проверить корректность модификации файла настройки клиента АІО, выполнив команду 
ііеасі- 25 /еіс/аісі/аісі. сопі, при этом должны быть установлены следующие параметры: 
«8ЕЕѴЕЕ = азіга-зегѵег. ехатріе. ги» и «ООШ/Л/ = . ехатріе. ги». 

11. Проверить корректность включения компьютера азіга-сіі- еп12. ехатріе. ги в домен «. 
ехатріе. ги». Для этого выполнить следующую последовательность действий: 

•в ОССН АзІгаЗегѵег перезапустить графическую утилиту «Политика безопасности», 
затем открыть вкладку «Домен АІ_Э» и выполнить подключение к домену; 



•выбрать узел «Компьютеры» и проверить, что в состав домена с именем «. ехатріе. ги» 
входит клиент Аій азіга-сІіепі2. ехатріе. ги; 

•открыть узел «Привилегии домена» — «изегаід», в поле «Компьютеры» добавить «азіга- 
сІіеп12. ехатріе. ги» к списку разрешённых компьютеров; 

•выйти из ОССН. 

12. Проверить функционирование сетевой файловой системы при доступе к домашним 
каталогам учётных записей пользователей АІ-О. Для этого выполнить следующую 
последовательность действий: 

•войти в ОССН АзігаСІіепі2 в графическом режиме с учётной записью пользователя 
изегаід; 

•в ОССН АзігаСІіепі2 в графической утилите «Менеджер файлов» открыть каталог 
«Документы», создать в нем текстовый файл с именем ііІе-ігот-аІЗ. Ш, затем открыть 
данный файл в редакторе диНед и добавить строку «Создан на ЦК 3»; 

•в ОССН АзігаСІІепі 1 в сессии, функционирующей от имени учётной записи пользователя 
изегаід, в графической утилите «Менеджер файлов» открыть каталог «Документы» и 
проверить наличие файла с именем ІіІе-ігот-аІЗ. іхі; 

•в ОССН АзІгаЗегѵег запустить терминал Р/у и перейти в каталог /аід-ехрогі-іюте 
командой сд /аід-ехрогі-іюте; 

•вывести содержимое текущего каталога командой Із, проанализировать результат; 
•определить дискреционные и мандатные атрибуты каталога изегаід командой рдр-Із -М; 
•выполнить попытку перехода в каталог изегаід и проанализировать выводимые ошибки; 
•запустить терминал Р/у в «привилегированном» режиме командой зидо ііу-іегт, 
запустить Мідпідді Соттапдег командой тс и перейти в каталог Іаід-ехрогі- 
Іюте/изегаІд/ІОЮсОхОЮхО/ Документы; 

•вывести в терминал содержимое файла ІіІе-ігот-аІЗ. іхі командой саі ІіІе-ігот-аІЗ. Іхі. 

13.Осуществить настройку политики паролей учётных записей пользователей АІ-О. Для этого 
выполнить следующую последовательность действий: 

•в ОССН АзІгаЗегѵег в графической утилите «Политика безопасности» выбрать «Домен 
/4/.0» (при необходимости выполнить подключение к домену), далее «Политики 
паролей» — « деТаиІі»; 

•во вкладке «Общие» в поле «Минимальная длина» ввести значение 5; 

• перейти к узлу «Пользователи» — «изегаід» и сменить пароль на «1234», а затем на 
«Азді'І ». 

14.Создать учётную запись пользователя Л/.0 с использованием утилиты аід-адтіп. Для 
этого выполнить следующую последовательность действий: 

•в ОССН АзІгаЗегѵег запустить терминал Р/у; 



•создать новую учётную запись пользователя АІО командой аід- адтіп изег-асід изегаІд2, 
задать новый пароль в соответствии с требованиями политики безопасности (не менее 
5 символов): «Оѵѵегі»; 

•далее все параметры учётной записи пользователя АІО, установленные по умолчанию, 
за исключением последнего (там значение «уез»); 

• вывести список учётных записей пользователей и компьютеров АІО командами аісі- 

асітіп изег-Іізі и аісі-асітіп ііозі-Іізі соответственно; 

•создать группу компьютеров аІсІ_ііозІ_дгоир'\ со следующим составом: азіга-сІіеШ 1. 
ехатріе. ги, азІга-сІіепі2. ехатріе. ги, командой аісі-асітіп йдгоир-асісі аІсІ_іюзІ_дгоир'\ - 
ііоз1=аз1га-сІіепР. ехатріе. ги-ІюзІ=азІга-сІіеп12. ехатріе. ги (также второй узел можно 
включить в группу командой аісі-асітіп іідгоир-тосі аІсІ_ііоз{_дгоир'\ -асісі-ііозіз- 
ііозІ=азІга-сІіепІ2. ехатріе. ги); 

• в графической утилите «Политика безопасности» проверить наличие узла «Группы 

компьютеров/ аІсІ_ІюзІ_дгоир1»; 

•модифицировать группу компьютеров аІсІ_ііозІ_дгоир'\, добавив в неё компьютер азіга- 
зегѵег. ехатріе. ги командой аісі-асітіп іідгоир-тосі аі^ііоз^дгоирі -асісі-ііозіз — 
ііозіз=азІга-зегѵег. ехатріе. ги; 

•добавить учётной записи пользователя изегаІсІ2 привилегию доступа к группе 
компьютеров аІсІ_ІюзІ_дгоир'\ командой аісі-асітіп изег-аісі-сар изегаІсІ2-ііозІ- 
дгоир=аІсІ_ііозІ__дгоир1 -асісііюзіз; 

• в графической утилите «Политика безопасности» проверить наличие компьютера азіга- 

зегѵег. Ехатріе. ги и в узле «Группы компьютеров» — «аІсІ_ІюзІ_дгоир'\» и наличие 
привилегии доступа к группе компьютеров аІсІ_ііозІ_дгоир1 у учётной записи 
пользователя изегаІсІ2 ш , 

• проверить возможность входа в ОССН АзІгаСИеп1 1 и АзІгаСІіеШ 1 с учётной записью 

пользователя изегаІсІ2, после успешной проверки выйти из ОССН АзІгаСІіеШ 1 и 
АзІгаСИеШ2. 

15.Осуществить проверку целостности и настроек АйО, для чего выполнить команду адд- 
аётіп ІезііпІедШум обратить внимание на выдаваемые предупреждения. 

16.Перейти к администрированию учётной записи пользователей домена: 

• в ОССН АзІгаЗегѵег в графической утилите «Политика безопасности» выбрать «Домен 

АІО»; 

•настроить параметры мандатного управления доступом учётной записи пользователя 
изегаІсІ2: установить в вкладке «МРД» максимальный уровень доступа 3, минимальный 
- 0 ; 



•настроить параметры мандатного управления доступом учетной записи пользователя 
изегаісі-, установить в вкладке «МРД» максимальный уровень доступа 2, минимальный 
- 0 ; 

•для проверки войти в ОССН АзігаСІіепІІ в графическом режиме с учётной записью 
пользователя изегаісі (уровень доступа — 2, неиерархические категории — нет, 
уровень целостности — «Низкий»); 

•выполнить команду аісі- асітіп іезі-іпіедгііу и проверить отсутствие предупреждений. 

17.Выполнить проверку функционирования единого задания устройств в АІО: 

• в ОССН АзІгаЗегѵег в графической утилите «Политика безопасности» выбрать «Домен 

АІО»; 

•открыть «Устройства и правила», «Правила», создать новое правило: выбрать импорт 
свойств, затем выполнить подключение ІІЗВ-носителя, в появившемся дереве 
выбрать устройство, ввести имя правила «Ниіе 1», отметить «Включено» и применить 
изменения; 

•открыть «Устройства и правила», «Устройства», выполнить добавление ІІЗВ-носителя 
через импорт свойств, затем установить для него разрешения на чтение и запись для 
учётной записи пользователя изегаісі, группы «Оотаіп ІІзегз» и всех остальных, 
установить уровень конфиденциальности — 1, выбрать правило «КиІеІ» и 
активировать данное устройство, установив флаг «Включено»; 

• войти в ОССН АзІгаСІіепП , в сессии, функционирующей от имени учётной записи 

пользователя изегаісі, на уровнях доступа 0, 1 и 2, выполнить подключение ІІЗВ- 
носителя, при этом проверить возможность монтирования (в соответствии с 
«Руководством администратора. Часть 1» монтирование учтённого носителя с 
файловой системой ѴРАТ возможно только при входе в ОССН на том же уровне, с 
которым данный носитель учтён) и корректность (соответствие МРОСЛ ДП-модели) 
выполнения операций записи и чтения файлов на ІІЗВ-носитель для каждого уровня 
доступа. 

Содержание отчёта по выполненной работе 

В отчёте о выполненной работе необходимо указать: 

1 .Полный перечень использованных команд с кратким описанием их назначения. 

2.Примеры выполнения команд, которые были использованы в ходе работы с описанием 
результатов их выполнения. 

3.Описание порядка работы с командами АІО (аісі-асітіп, аісі- іпіі, аісі-сііепі) и графической 
утилитой «Политика безопасности» (Ну асітіп зтс) при осуществлении следующих 
действий со службой АІО: 

•настройка адресации сетевого интерфейса; 



•настройка контроллера ЛІО; 

•настройка клиента ЛІО; 

•управление параметрами контроллера ЛІО. 

Контрольные вопросы 

1 .Каково назначение служб контроллера ЛІО? 

2. Какие службы устанавливаются на контроллере ЛІО? 

3. Какие особенности настройки имён компьютеров в домене ЛІО? 

4. Каковы особенности настройки контроллера ЛІО? 

5. Каковы особенности настройки клиента ЛІО? 

б.Чем отличаются настройки ЛІО в режимах контроллера и клиента? 

/.Какие основные настройки домена можно выполнять с использованием команды аід-адтіп? 



4.8. Лабораторная работа № 8. 
Управление программными пакетами. Настройка 

системных служб 


Цель работы 

Изучить порядок администрирования пакетов ОССН, в том числе используемых для этого 
команд и графических утилит, а также особенности настройки системных служб (демонов). 
Время выполнения работы 4 академических часа. 

Краткие теоретические сведения 

Система управления пакетами ОССН включает несколько команд и утилит, которые могут 
работать в режиме командной строки, в псевдографическом и графическом режимах. При 
этом порядок действий при их использовании для изменения состава установленных в ОССН 
пакетов принципиально не отличается, за исключением, возможно, установки 
взаимосвязанных пакетов. 

Для управления пакетами используются утилиты аріііисіе, «Менеджер пакетов 8упарііс», 
команды системы управления пакетами АРТ и команда фкд. 

Утилита аріііисіе имеет следующий интерфейс: 

Файл Правка Настройка Помощь 

,• с г ѵ ::в- 



-— НеустаноВленныв пакеты (2280) 
-— Виртуальные пакеты (614) 


Эти пакеты уже установлены на Вашем компьютере. 
В этой группе содержится 1311 пакетов. 


I із 1 


Она позволяет осуществлять установку, удаление, поиск по именам (в том числе 
неустановленных) и управление зависимостями пакетов. 

При просмотре пакетов отображается состояние каждого пакета (первый символ в 
списке): и — виртуальный, В — неработоспособный, и — «распакованный», С — 
недонастроенный, Н — недоустановленный, с — удалённый, но с сохранёнными файлами 
настроек /—установленный и Е — внутренняя ошибка. Вторым символом может быть указан 
флаг автоматизации, означающий, что пакет был установлен как зависимость. Удобство 
использования данной утилиты также заключается в автоматическом формировании набора 
пакетов, которые являются зависимыми от удаляемого пакета. Это позволяет предотвратить 






























нежелательное удаление используемых пакетов при настройке других пакетов. После 
выбора необходимого набора действий их выполнение производится по нажатию «д» — 
загрузка/установка/удаление пакетов. Кроме графического, представления утилита аріііис/е 
может быть использована как консольная команда с параметрами. 

Управление пакетами посредством АРТ выполняется командами, основными из которых 
являются: арі - деі, арі - ссігогп, арі - сасііе и арі - сопіід. 

Команда арі - сс/гот предназначена для добавления в систему нового источника 
пакетов (репозитория), как правило, диска СО/ ОѴР. По умолчанию при установке ОССН один 
источник уже добавлен — это установочный диск ОССН. Настройки источников пакетов 
хранятся в файле /еіс/арі/зоигсез.Нзі. Данный файл настроек используется как командами 
вида арі*, так и утилитой аріііис/е. После установки ОССН он содержит единственную запись: 
с/еЬ сс/гот: [Название диска]/ зтоіепзк сопігіЬ таіп поп - ігее. Первый элемент со значением 
с/еЬ указывает на тип источника — с/еЫап раскаде. При использовании диска с исходными 
текстами вместо записи с/еЬ будет стоять с/еЬ - зге. Второй элемент со значением сс/гот 
указывает носитель источника — устройство типа сс/гот. Для установки по сети может 
использоваться значение Ыір. Далее указана метка диска в квадратных скобках и путь: «/». 
Затем расположен элемент с указанием названия дистрибутива: зтоіепзк. После этого поля 
указываются наборы установочных пакетов: сопігіЬ, таіп, поп - ігее. Данные названия 
наборов для источника сс/гот соответствуют подкаталогам каталога рооі, расположенного в 
корне диска. Каждый новый источник заносится новой строкой в данный файл. Для 
игнорирования строки поддерживаются комментарии (в начале строки указывается символ 
«#»), 

В случае, если файл /еіе/ арі/зоигсез.Іізі редактируется вручную, то для обновления 
списка пакетов необходимо выполнить команду арі - деі ирс/аіе. Данная команда по списку 
активных источников, полученных из этого файла, считывает соответствующие наборы 
пакетов, которые далее используются для выбора устанавливаемых пакетов при выполнении 
команды арі - деі Іпзіа/І имя_пакета. 

Для непосредственного управления пакетами используются команды арі - деі іпзіаі/ 
имя_пакета (установка), арі - деі гетоѵе имя_пакета (удаление). 

Команда арі-сасЬе применяется для работы с кэшем пакетов. Она позволяет вывести список 
пакетов — арі - сасЬе ркдпатез, зависимости отдельного пакета — арі - сасЬе сіерепс/з 
имя_пакета, найти пакет в кэше по его имени — арі - сасЬе зеагсЬ. 

Команда с/ркд реализует следующие основные действия: 

• с/ркд - і имя_файла_с/еЬ_пакета — установка пакета, находящегося в файле 
имя_файла_с/еЬ_пакета (данный файл имеет расширение ЫеЬ)\ 

• с/ркд - г имя_пакета — удаление пакета; 



• сіркд - і имя_пакета — вывод файлов, содержащихся в пакете; 


• сіркд - 5 имя_файла — поиск принадлежности заданного файла конкретному пакету 
Управление пакетами с использованием графического интерфейса осуществляется 
графической утилитой «Менеджер пакетов «8упарііс» (зупарііс), имеющей следующий 
интерфейс: 


Файл Правка Пакет Настройки Справка 

О © 

Обновить Отметить все обновления 


! Іриі.'-е» 


( ВОЙ» • 


о. 

Поиск 


0а(аЬа5е 


□ 389-с1з-Ьа5е 


іаѵаБсгірі Ргодгатіттіпд (.аг, д звэ-сІз-Ьазе-ІіЬз 


□ а2р5 
И асі 


Установленная в Последняя перси Описание 

1.3.7.10-1 иЬипіи 389 Оігесіогу Бегѵег зиі(. 
1.3.7.10-1 иЬипІи' 389 Оігесіогу Бетѵег эиіі 
1:4.14-2 ОГЛІ а2рь - ’АпуіЬіпд іо I 

2.2.52-3 2.2.52-3 Лссе55 сопітоі ІІ5І иіІІІІІе' 


Ну 

Пу(не свободный) 

[ _' 'ІІ -ч Пакеты не выбраны. 

Состояние 
Происхождение 
Специальные фильтры 

‘.Г7~ .7 ' I 

I Результаты поиска 
Архитектура 

3021 пакетов в списке, 1594 установлено, 0 с ошибками, О для устанооки/обновленип, 0 для удаления 


Она позволяет осуществлять фильтрацию пакетов по состоянию, устанавливать 
зависимости, устанавливать, переустанавливать, удалять и полностью удалять пакеты. В 
свойствах пакетов, отображаемых утилитой, содержится информация о файлах, которые 
были установлены этим пакетом с их расположением в ОССН, зависимости пакетов и 
доступные версии пакетов. 

Для настройки системных служб в ОССН используются команды зегѵісе (устаревшая) 
и зузіетсіі и графическая утилита зузіет - сідепіе (запуск с использованием графического 
меню осуществляется в меню «Система», «Инициализация системы»), В ОССН версии 1.6 
используется новый менеджер загрузки Зузіетсі. С этим связаны значительные изменения 
порядка управления и создания сервисов. 

Для управления запуском системных служб как и ранее может использоваться команда 
зегѵісе имя_службы <команда>. В качестве параметров команды используются зіагі, зіор, 
гезіагі, зШизцпя запуска, останова, перезапуска или определения статуса системной службы 
соответственно. С использованием утилиты зузіетсіі запуск сервиса (в данном случае — 
юнита) выполняется командой зузіетсіі зіагі имя_юнита (аналогичные команды 
используются для останова — зіор, перезапуска — гезіагі). Просмотр уровней запуска 





















системных служб может быть осуществлён с использованием команд зегѵісе — зіаіиз - аІІ или. 
более наглядной зузіетсіі — аІІ Іізі - ипііз. Аналогичные функции реализует графическая 
утилита зузіетсідепіе. 

Используемое методическое и лабораторное обеспечение 

• ОССН версии 1.6, в которой создана учётная запись пользователя изег, с 
параметрами: максимальный и минимальный уровни доступа — 0, неиерархические 
категории — нет, уровень целостности — «Высокий», входит в группу администраторов 
— азіга - асітіп (вторичная группа), разрешено выполнение привилегированных команд 
(зисіо). 

• Дистрибутив ОССН. 

• Документация: «Операционная система специального назначения «Азіга Ипих ЗресіаІ 
Есііііоп». Руководство администратора. Часть 1», «Операционная система специального 
назначения «Азіга Ипих ЗресіаІ Есііііоп». «Руководство по КСЗ. Часть 1», «Операционная 
система специального назначения «Азіга Ипих ЗресіаІ Есііііоп». Руководство 
пользователя». 

• Для выполнения работы в течение двух занятий необходимо обеспечить возможность 
сохранения состояния ОССН за счёт применения технологий виртуализации (создания 
виртуальных машин с ОССН). 

Порядок выполнения работы 

• Начать работу со входа в ОССН в графическом режиме с учётной записью 
пользователя изег (уровень доступа — 0, неиерархические категории — нет, уровень 
целостности — «Высокий»), 

• Запустить терминал ЕІу и перейти в каталог /еіс/арі. 

• Вывести дискреционные права доступа к файлу зоигсез. Іізі командой Із- I зоигсез.Іізі. 
Определить возможность изменения файла при работе от имени данной учётной записи 
пользователя. 

• Выполнить команду зисіо Ну - іегт и перейти в каталог /еіс/арі. 

• Запустить Місіпідііі Соттапсіег командой тс. Открыть для редактирования файл 
зоигсез.Іізі и закомментировать строку с/еЬ ссігот... путём установки символа # в начале 
строки. 

• Выполнить команду арі - деі ирсіаіе, и с использованием дистрибутива ОССН добавить 
источник пакетов ссігот командой арі - ссігот асісі. 

• Установить пакет ѵіт - дік командой арі - деі іпзіаіі ѵіт - дік. Проверить возможность 
работы в редакторе ѵіт - дік, выполнив команду ѵіт.дік 1 .1x1. Выйти из редактора, набрав 
«:щ». Проверить наличие файла \.іхі\л удалить его командой гт 1 Лхі. 



• Запустить второй терминал Р/у командой зидо Пу - іегт и в нём выполнить команду 

аріііисіе: 



— Виртуальные пакеты (В91) 


Эти пакеты уже установлены на Вашем компьютере. 
3 этой группе содержится 15Ѳ6 пакетов. 


• В первом терминале выполнить попытку удаления пакета ѵіт - дік командой арі - деі 
гетоѵе ѵіт - дік, проанализировать выводимые ошибки: 

гооІШазІга:/Н арі-деі гетоѵе ѵіт-дік 

Е: Не удалось получить доступ к файлу Блокировки /ѵаг/1іЬ/гіркд/Іо 
ск - ореп (11: Ресурс временно недоступен) 

Е: Не удалось выполнить блокировку управляющего каталога С/ѵаг/Іі 
Ь/с1ркд/); он уже используется другим процессом? 
гооІШавіга:/Н арі-деі гетоѵе ѵіт-дік 

Е: Не удалось получить доступ к файлу блокировки /ѵаг/1і Ь/вркд/ 1оск 
- ореп (11: Ресурс Временно недоступен) 

Е: Не удалось выполнить блокировку управляющего каталога (/ѵаг/ІіЬ/ 
гіркц/); он уже испольэцется другим процессом? 

• Завершить аріііисіе во втором терминале. В первом терминале повторить удаление 
пакета ѵіт - дік командой арі - деі гетоѵе ѵіт - дік и арі - деі гетоѵе ѵіт - диі - соттоп. 
Проанализировать отображаемые в терминале сообщения и определить число 
удалённых пакетов. 

• Выполнить настройку пакетов с использованием АРТ, для этого осуществить 
следующую последовательность действий: 

• найти пакеты, содержащие модули для ѴѴеЬ - сервера Арасііе2, командой арі - сасііе 
зеагсіі ііЬарасііе2 - тосі - * и определить их назначение по описанию; 

• выполнить установку пакета іехзіисііо командой арі - деі іпзіаіі іехзіисііо: 

• выполнить очистку локального хранилища файлов пакетов за исключением А/аг/сасііе/ 
арі/ агсіііѵез/ и /ѵаг/ сасііе/ арі/ агсЬіѵез/рагііаі/ командой арі - деі сіеат, 

• выполнить очистку локального хранилища командой арі - деі аиіосіеап ; 

• удалить пакет іехзіисііо с удалением конфигурационных файлов командой арі - деі 
ригде ІІЬдиахірБ -1; 

• выполнить повторную установку пакета іехзіисііо командой арі - деі іпзіаіі іехзіисііо и 
определить число установленных пакетов; 












• проверить назначение и зависимости пакета Іехзіисііо командами арі - сасііе зіюѵѵ 
Іехзіисііо и арі - сасііе зіюѵѵркд Іехзіисііо; 

• выполнить удаление пакета Іехзіисііо с сохранением конфигурационных файлов 
командой арі - деі гетоѵе Іехзіисііо и проанализировать число удаляемых пакетов и 
отсутствие сообщения об очистке файлов настроек; 

• проверить наличие ошибок в зависимостях пакетов командой арі - деі -1 іпзіаіі] 

• выполнить удаление лишних пакетов, которые были установлены автоматически, но 
теперь не требуются командой арі - деі аиіогетоѵе. 

• В первом терминале выполнить команду аріііисіе и открыть раздел «Неустановленные 
пакеты» — «Есіііогз» — «таіп». 

• Для работы с пакетом ѵіт - дік осуществить следующие действия: 

• выполнить просмотр следующих свойств пакета ѵіт - дік: описание назначения, размер 
в сжатом и распакованном виде, версии и зависимости: 


,<отсиТстВиет> 2:8.0.019 


Описание: Ѵі ІМргоѵегі - епЬапсес! ѵі есіі іог - ыііб 6ТК2 601 
Ѵіт із ап аіпозі сопраііЫе ѵегзіоп оГ ІЬе 1)ШХ есіі іог Ѵі. 


Мапу пей Геаіигез Ьаѵе Ьееп асісіесі: оиііі Іеѵеі ипОо. зупіех ЬідМідЫіпд. сотяапсі 
Ьізіогу. оп-Ііпе Ьеір. Гііепате сожріеііоп. Ыоск орегаііопз. Гоійіпд, Ііпісосіе зирі 
еіс. 
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Домашняя страница: ЫІр:// ыуш. ѵіш.огд/ 

Приоритет: дополнительный 
Раздел: есіііогз 

Сопровождающий: ОеЬіап Ѵіп Маіпіаіпегз <ркд-ѵіп-таіпІаіпег5@1ізіз.а!іоіЬ.с1еЬіап.огд> 

Нрхитектдра: агсібч 

Размер 0 сжатом Виде: 1 263 к 

Размер В распакованном Виде: 3 0*10 к 

Пакет с исходным кодом: ѵіп 

Происхождение: 1.б/5іаЬІе (атс!64) 

11РІ происхождения: сс!гот:[05 Йзіга Ьіпих 1.6 зтоіепзк - атс!6<] 0Ѵ0 1/рооІ/таіп/ѵ/ѵіт/‘ 
Ѵі ІПргоѵесІ - епЬапсес! ѵі есіі Іог - иіІЬ СТК2 СШ 


• в третьей строке в псевдографическом интерфейсе перейти к вкладке «Пакет» и выбрать 
данный пакет для установки нажатием клавиши «+», обратив внимание, что одновременно 
с его установкой были добавлены его зависимости: пакет ѵіт - диі - соттоп ; 

• определить статус установки пакетов: ѵіт - дік — рі (пакет помечен для установки), ѵіт - 
диі - соттоп — ріА (пакет помечен для установки и выбран автоматически в качестве 
зависимого); 

• выполнить установку и получить следующие данные: перечень устанавливаемых пакетов 
(1 пакет — ѵіт - дік), пакеты, которые 

устанавливаются автоматически, список пакетов, предлагаемых другими пакетами (первые 
две группы пакетов устанавливаются полностью, а последняя может быть дополнительно 
выбрана при установке). 

• С использованием утилиты аріііисіе выполнить следующие действия: 




• проверить назначение и зависимости пакета іехзіисііо командами арі - сасііе зііоѵѵ 
іехзіисііо и арі - сасііе зііоѵѵркд іехзіисііо; 

выполнить попытку удаления (« - ») пакета ѵіт - диі - соттоп и проанализировать 
выведенные предупреждения; 

• нажать клавишу «е» для того, чтобы определить какие дополнительные действия 
необходимо будет выполнить совместно с удалением пакета ѵіт - диі - соттоп, затем 
нажать клавишу «ТА В» для выбора «Удалить ѵіт - дік», далее нажать «.» для выбора 
решения удалить «Действия: 1 оставить неизменным», затем «!» и «д» для применения 
предложенных действий; 

проверить, какие пакеты были дополнительно помечены для удаления, и удаляется ли 
при этом пакет ѵіт - дік ; 

выделить для удаления пакет папо и в строке статуса (третья строка) определить размер 
освобождаемого места на диске. 

• Выполнить попытку удаления пакета ѵіт - диі - соттоп, при этом осуществить 
следующие действия: 

отметить для удаления пакет ѵіт - диі - соттоп выбором пункта меню «Пакет/Удалить» и 
проверить выделение для удаления зависимых пакетов; 

отменить данные действия выбором пункта меню «Действия/ Отменить незаконченные 
действия» и выйти из утилиты аріііисіе. 

• Выполнить удаление пакета ѵіт - диі - соттоп командой арі - деі гетоѵе ѵіт - диі - 
соттоп, проверить список удаляемых пакетов. 

• Выполнить удаление пакета папо командой арі - деі гетоѵе папо и проверить список 
удаляемых пакетов. 

• Выполнить установку пакетов с использованием команды сіркд, при этом осуществить 
следующие действия: 

в «привилегированном» режиме терминала Р/у перейти в каталог /тесііа/ссігот/рооі/таіп/ 
п подключённого О ѴО с дистрибутивом ОССН; 

для установки пакета папо найти соответствующий каталог командой /з | дгер «*папо» и 
перейти в него; 

установить пакет папо командой фкд - і имя_файла_пакета, затем проверить работу 
редактора папо; 

выполнить переход в каталог рооі/таіп; 

перейти в каталог ѵ/ѵіт и осуществить попытку установки пакета ѵіт - дік командой сіркд 
— іпзіаІІ имя_файла_пакета и проанализировать результат (пакет ѵіт - дік будет не 
настроен). 



• Выполнить проверку статуса установленных пакетов, для чего осуществить 
следующие действия: 

в «привилегированном» режиме терминала Р/у запустить утилиту аріііисіе и 
проанализировать предупреждения; 

нажать клавишу «е» для просмотра решений: первое решение — это установка пакета ѵіт 
- диі - соттоп; 

выполнить просмотр следующего решения и выйти из утилиты аріііисіе. 

• Вернуться в терминал Р/у и выполнить следующую последовательность действий: 
установить недостающий пакет (ѵіт - диі - соттоп) командой сіркд — іпзіаіі 
имя_файла_пакета; 

запустить утилиту аріііисіе и проанализировать причину отсутствия ошибочных 
зависимостей и требований установки дополнительных пакетов; 

вернуться к вкладке «Пакеты» и перейти «Установленные пакеты» — «есіііогз» — «таіп», 
далее выделить в списке пакет ѵіт - дік и определить его статус; 

выйти из утилиты аріііисіе и в терминале Р/у выполнить конфигурацию ѵіт - дік командой 
сіркд — сопіідиге ѵіт - дік и проверку возможности запуска командой ѵіт.дік; 
проверить в приложении аріііисіе, что статус пакета ѵіт - дік изменился на «/» (т. е. пакет 
был сконфигурирован и теперь успешно установлен). 

• Вывести в терминал Р/у информацию об установленном пакете ѵіт, для чего 
осуществить следующие действия: 

вывести в терминал содержимое пакета ѵіт - дік командой сіркд - /. ѵіт - дік; 
вывести в терминал содержимое пакета ѵіт - дік командой аріііисіе зііоѵѵ ѵіт - дік] 
вывести в терминал список пакетов, имя которых начинается с ѵіт, командой аріііисіе 
зеагсіі " л ѵіт" \л определить статусы их установки; 

вывести в терминал список пакетов, имя которых содержит дік, командой аріііисіе зеагсіі 
"дік"] 

определить принадлежность файла /изг/зііаге/Ііпііап/оѵеггісіез/ѵіт - дік пакету ѵіт, для чего 
выполнить команду сіркд - 8/изг/ зііаге/Ііпііап/оѵеггісіез/ѵіт - дік] 

вывести в терминал список пакетов, содержащих файлы, полный путь с именем которых 
заканчивается на «Іѵіт» командой сіркд - 8 "*/ѵіт". 

• Выполнить настройку пакетов в графической утилите Зупарііс, для чего осуществить 
следующие действия: 

запустить графическую утилиту Зупарііс, при этом ввести пароль текущей учётной записи 
пользователя для возможности работы в «привилегированном» режиме; 



открыть меню «Настройки», «Репозитории» и проверить наличие неактивного 
репозитория, который был ранее закомментирован в файле зоигсез.Іізі ; 
скопировать ІІНІ для неактивного репозитория; 
удалить неактивный и активный репозитории. 

• В графической утилите Зупарііс через меню «Настройки», «Репозитории» выбрать 
действие «Создать», при этом: 

в элемент ІІНІ ввести запись ссігот: [ОЗ Азіга Ипих 1.6 зтоіепзк - атсІСА ОѴО\/\ 
о в элемент «Дистрибутив» — зтоіепзк ; 
в элемент «Разделы» — сопігіЬ таіп поп - ігее ; 

закончить изменения и выполнить обновление для повторного считывания источника 
пакетов: 


.* Менеджер плкетоо іуплрііс 

Файл Правка Пакет Настройки Справка 



Обновить 


Оз;лЬагс 


• В графической утилите Зупарііс выполнить следующую последовательность действий: 
в элемент «Быстрый фильтр» ввести «ѵіт» и отметить пакет ѵіт - соттоп для полного 
удаления с использованием контекстного меню, после удаления проанализировать 
предупреждения ОССН; 

выбрать в списке фильтров «Ошибки зависимостей» и отметить пакет ѵіт для полного 
удаления, и после удаления проанализировать список полностью удаляемых пакетов, их 
число и суммарный объем дискового пространства; 

в «привилегированном» режиме терминала Р/у выполнить попытку удаления пакета папо 
командой арі - деі гетоѵе папо и проанализировать предупреждения ОССН; 
завершить работу с графической утилитой Зупарііс, выполнить удаление пакета папо 
командой арі - деі гетоѵе папо. 

• Для управления системными службами выполнить следующую последовательность 
действий: 

в «привилегированном» режиме терминала Р/у получить текущие статусы запускаемых 
системных служб командой зегѵісе — зіаіиз - аII] 

выполнить попытку определения статуса системной службы аѵаііі - сіаетоп командой 
зегѵісе аѵаііі - сіаетоп зіаіиз и проанализировать результат; 

для анализа порядка вызова команды зегѵісе вывести на экран содержимое файла аѵаііі 
- сіаетоп командой саі/еіс/іпіі.сі/аѵа - ііісіаетоп; 








• аналогично по содержимому файла аѵаііі - даетоп найти реализацию вызова команды 
зіаіиз ; 

• вывести в терминал содержимое файла аѵаііі - сіаетоп командой саі/еіс/іпіі.сі/аѵаііі - 
сіаетоп и проанализировать его структуру, при этом найти особенности реализации 
вызова команды зіаіиз. 

• Для управления запуском системных служб в «привилегированном» режиме 
терминала Р/у осуществить следующие действия (при этом проверяется обратная 
совместимость с службой инициализации): 

• определить статус загрузки системной службы ззіі командой зегѵісе — зіаіиз - аІІ / дгер ззіі 
и командой Із/еІс/гс2.сІІ дгер ззіі] 

• установить запуск службы сервера ззіі на уровнях по умолчанию командой ирсіаіе - гс.сі 
ззіі епаЫе] 

• определить изменения в статусе системной службы ззіі командой зегѵісе — зіаіиз - аіі / 
дгер ззіі и командой Із/еІс/гс2.сІІдгер ззіі] 

• выполнить остановку, запуск и перезапуск системной службы ззіі командами зегѵісе ззіі 
зіор, зегѵісе ззіі зіап, зегѵісе ззіі гезіагі. 

27. Осуществить запуск системных служб из графической утилиты «Инициализация системы» 

(зузіетсідепіе), осуществив следующие действия: 

• в «привилегированном» режиме терминала Р/у запустить графическую утилиту 
«Инициализация системы» командой зузіетсідепіе &: 



Файл Вид Демон Юннт Сеанс Настройка Справка 


> 

Системные юниты Конфигурационные файлы Сеансы Таймеры 

I_) Показать неактивные ч ' • •> 

ѵ Состояние загрузки Состояние активности Состояние кжита 


• запретить запуск системной службы ззіі, для этого выделить юнит ззіі.зегѵісе, в 
контекстном меню выбрать «Отключить юнит»; 

• выполнить перезагрузку и повторный вход в ОССН; 


Все 

Юнит 







• проверить настройку службы зз/і командой зегѵісе — зіаіиз - а// и с использованием 
графической утилиты «Инициализация системы» (при этом юнит ззіі.зегѵісе должен 
отсутствовать); 

• повторно активировать службу ззіі с помошью ирсіаіе - гс.сі, выполнить перезагрузку; 

• запустить графическую утилиту «Инициализация системы» в столбце «Юнит» выделить 
55/7, в контекстном меню выбрать «Редактировать файл юнита» и определить зависимость 
запуска данной службы от других служб в открывшемся окне (раздел [ ІІпіі] параметр Аііег)\ 

• вывести в терминале Р/у содержимое начала файла /еіс/іпіі.сі/ззіі командой 
ііеасі/еіс/іпіі.сі/ззіі и сравнить запись Яедш'гес/ - ЗіаП с содержимым окна ззіі в графической 
утилите «Инициализация системы»; 

• активировать службу пір с использованием ирсіаіе-гс.сі, выполнить перезагрузку: 
гею Іга : /Ьоте /иэегй ирсіаІе-гс . сі пір епйЬІ® 

• в графической утилите «Инициализация системы» в столбце «Юнит» найти службу л/р, 
затем в контекстном меню выбрать «Маскировать юнит»: 

Сисѵфммыс юмить* • -оімт/л • .. Комфигурлциоммьн> флИліи • Сеансы Тайгиоры 

Осо ^ | Покозоть нелктионыс I П ■ • **м .«►.!•• 


Юнит 

Состоймио загрулки Состолнис лктионости 

Состоя»-*ие юнита 


Іо .«сіе с! .кііѵо 

АСМѵе 

&ХІІШІ 

шт 


йббШі':.. 


• проверить статус системной службы пір командой зузіетсіі Іізі - ипііз (для этого выполнить 
поиск «пір» с использованием комбинации клавиш «/» и «пір»), что системная служба 
замаскирована, выполнить перезагрузку и проверить статус загрузки службы. 

Содержание отчёта по выполненной работе 
В отчёте о выполненной работе необходимо указать: 

• Полный перечень использованных команд с кратким описанием их назначения. 

• Примеры выполнения команд, которые были использованы в ходе работы с описанием 
результатов их выполнения. 

• Описание порядка работы при осуществлении следующих действий: 

• удаление пакета без зависимостей; 

• удаление пакета с зависимостями; 

• установка новых пакетов; 

• создание новых репозиториев; 

• редактирование действующих репозиториев и обновление информации о пакетах. 

• Описание порядка работы при установке и удалении пакетов с использованием утилит 
аріііисіе, «Менеджер пакетов Зупарііс», команд АРТ и команды сіркд. 



• Описание особенностей функционирования команды сіркд при установке пакетов с 
зависимостями. 

6. Описание порядка работы с командами и графической утилитой «Инициализация системы» 
(зузіетсідепіе) при осуществлении следующих действий с системными службами: 

• просмотр статуса; 

• просмотр настроек запуска системных служб; 

• управление (запуск, перезапуск, останов, просмотр состояния). 

Контрольные вопросы 

• Каковы особенности одновременной работы нескольких утилит управления пакетами? 

• Где и в каком формате хранятся настройки репозиториев? 

• Каким образом добавляются новые источники пакетов и осуществляется их повторное 
считывание? 

• Какие команды позволяют работать с зависимыми пакетами в автоматическом 
режиме? 

• Какие особенности выполнения команд удаления пакетов? 

• Как определить статус установленного пакета с использованием команды сіркд и 
утилиты аріііисіе ? 

• Как определить статус запуска системной службы? 

• Каким образом можно произвести останов, запуск, перезапуск системной службы? 

• Какие команды используются для просмотра состояния и уровней запуска системной 
службы? 



4. 9. Лабораторная работа № 9. 

Настройка защищенного режима работы ОССН в соответствии с Азіга 

□пых РесМЗоок 

Цель работы 

Изучить особенности настройки безопасной конфигурации компьютера для работы с ОССН в 
соответствии с Азіга Ипих Вед- Воок. 

Время выполнения работы 6 академических часов. 

Краткие теоретические сведения 

Выполнение лабораторной работы основывается на описании настройки безопасной 
конфигурации компьютера для работы с ОССН Азіга Ипих ЗресіаІ Едіііоп с использованием 
материалов справочного центра Азіга Ипих Вед-Воок. Совокупность данных настроек 
позволяет достичь режима работы ОССН, когда все её механизмы защиты будут 
активированы и полнофункциональны. 

Настройки включают конфигурирование ОССН по следующим направлениям: 

•доверенная загрузка ОССН; 

•конфигурирование оборудования компьютера с ОССН; 

•защитное преобразование данных на жёстком диске; 

•полнофункциональный режим работы мандатного контроля целостности; 

•контроль цифровой подписи 5І_Р-файлов; 

•отключение терминалов для непривилегированных учётных записей пользователей; 
•блокировка командных интерпретаторов и макросов для непривилегированных учётных 
записей пользователей; 

•блокировка установки бита исполнения; 

•блокировка трассировки исполнения программ; 

•использование межсетевого экрана; 

•работа в режиме киоска. 

Детали работы ОССН по большинству перечисленных направлений подробно рассмотрены 
в главах 1 и 3. Дополнительно справочные материалы по настройке защищённого режима 
работы ОССН приведены в документации «Руководство по КСЗ. Часть 1». 

Используемое методическое и лабораторное обеспечение 

• Подготовленный компьютер для установки ОССН Азіга Ипих Ипих ЗресіаІ версии 1.6, 
отвечающий требованиям к оборудованию для использования ОССН (при разбиении 
диска требуется жёсткий диск объёмом от 20 Гбайт). 

• Дистрибутив ОССН. 

• Документация: «Операционная система специального назначения «Азіга Ипих ЗресіаІ 
Едіііоп». Руководство администратора. Часть 1», «Операционная система специального 



назначения «Азіга Ипих ЗресіаІ Едіііоп». Руководство по КСЗ. Часть 1», «Операционная 
система специального назначения «Азіга Ипих ЗресіаІ Есііііоп». Руководство 
пользователя». 

• Для выполнения всей лабораторной работы необходимо использовать отдельный 
компьютер, а не виртуальные машины. 

Порядок выполнения работы 

• Для обеспечения доверенной загрузки ОССН выполнить установку и настройку (при 
наличии) аппаратно-программного модуля доверенной загрузки (АПМДЗ). 

• Выполнить предварительную конфигурацию оборудования компьютера: 

•настроить ВЮЗ: установить пароль блокировки входа в ВІОЗ (при задании пароля 
руководствоваться требованиями к генерации паролей, аналогичные требованиям к 
сложности паролей учётных записей пользователей ОССН); 

•при наличии в ВІОЗ опций блокировки установки битов исполнения (для процессоров ІпіеІ 
Ехесиіе ОізаЫе Віі и для процессоров АІѴЮ Л/о Ехесиіе Віі) включить их; 

•при наличии на серверах «недоверенных» систем контроля и управления вида НО, НЗА, 
ЮНАС, ТіііпкЗегѵег ЕазуМападе, АМТ, ІМапа необходимо выполнить их отключение, и 
использовать, при необходимости, альтернативные решения вида ІР КѴМ; 

•для /л/е/-платформ необходимо устранить уязвимость ІпіеІ-ЗА- 00086 в ІпіеІ Мападетепі 
Епдіпе (если он интегрирован в процессор) посредством установки обновления 
микропрограммы ІпіеІ Мападетепі Епдіпе (производитель оборудования должен обеспечить 
данную возможность: для этого могут использоваться либо обновления ВІОЗ, либо 
дополнительное ПО для интеграции обновлений); для проверки можно использовать утилиту 
ІпіеІ-8А-00086 Оеіесііоп ТооІ. 

• Перейти к установке ОССН, используя для этого первый установочный диск. Далее 
необходимо выполнить установку ОССН с включённым защитным преобразованием 
диска (для упрощения процесса установки может также быть использован режим «Авто 
— использовать весь диск с защитным преобразованием ІѴМ», так как данный режим 
содержит отключаемую стадию перезаписывания диска случайными данными перед 
установкой ОССН, стадию формирования ключевой фразы преобразования — длина от 
20 символов, которая будет использоваться для защиты разделов с использованием 
сіт-сгурі) и обеспечить невозможность физического доступа к жёсткому диску, на 
котором установлена ОССН. В рамках работы используется метод разметки «Вручную». 
Для выполнения всех вышеперечисленных операций необходимо выполнить: 

•осуществить загрузку с основного (установочного) диска ОССН; 

•выбрать язык «Русский», затем «Графическая установка»; 



•принять лицензионное соглашение, установить способ переключения языка, задать имя 
компьютера «азіга», имя учётной записи администратора «изег», задать и подтвердить 
пароль администратора (который удовлетворяет требованиям сложности), выбрать часовой 
пояс; 

•выбрать метод разметки «Вручную» и удалить все имеющиеся разделы; 

•в «свободном месте» выполнить создание нового раздела размером 300Мб («Первичный»), 
задать для него файловую систему Ехі 4 и точку монтирования /Ьооі, включить метку 
«загрузочный» и закончить изменения раздела; 

•в «свободном месте» выполнить создание нового раздела размером 2Гб («Первичный», 
позже он будет использоваться для каталога /Іюте), задать точку монтирования 
«отсутствует», закончить изменение раздела; 

•выполнить создание нового раздела размером 2,5Гб («Первичный», он будет 
использоваться для подкачки), указать использовать как «раздел подкачки»; 

•аналогично создать два логических раздела объёмом по 1 Гб (при выборе размера разделов 
следует помнить, что при размере раздела /Ітр менее 250Мб вероятно возникновение 
ошибок при работе с графикой или с большими объёмами данных), задать для них файловую 
систему: ЕхіЛ и точки монтирования /Ітр и /ѵаг/ітр (вводится вручную); 

•в свободном месте создать раздел «/» («Логический») и задать для него файловую систему 
Ехі4; 

•выбрать «Настроить защитное преобразование для томов», сохранить сделанные 
изменения разделов; 

•затем «Создать защитное преобразованные тома» и выбрать разделы, доступ к которым 
будет задаваться паролем: второй раздел с каталогом /Іюте (выбрать «Ключ защитного 
преобразования» — «Ключевая фраза»), третий раздел с подкачкой (выбрать «Ключ 
защитного преобразования» — «Произвольный ключ»); 

•закончить создание разделов; 

•выполнить стирание разделов; 

•задать «ключевую фразу для защитного преобразования» второго раздела (проверить, что 
запрос выдаётся именно для этого раздела) в соответствии с требованиями к сложности 
паролей; 

•задать тип использования и точки монтирования, созданные с применением защитного 
преобразования томов: зда2_сгурІ — /Іюте, здаЗ_сгурІ — подкачка (см. рисунок на 
следующей странице); 

•по окончании выбрать «Закончить разметку и записать изменения на диск» (см. рисунок на 
следующей странице); 



Перед вами список настроенных разделов и их точек монтирования. Выберите (тип 
файловой системы, точку монтирования и так далее), свободное место, что 
устройство, чтобы создать на нем новую таблицу разделов. 
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•выбрать необходимые для работы наборы пакетов, АІО не устанавливать, дополнительные 
параметры настройки ОССН не устанавливать, установить ОНІІВ в главную загрузочную за¬ 
пись (см. рисунок на следующей странице); 

Выберите устанавливаемое программное обеспечение: 



Рабочий стол РІу 

|</| Приложения для работы с сенсорным экраном 
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Н/| офисные средства 
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1_) Средства удаленного доступа 55Н 
0 Защищенный ѴѴЕ8 сервер 
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•установить пароль блокировки входа в настройке ОНІІВ (при задании пароля 
руководствоваться требованиями к генерации паролей). 


• Для дальнейшей настройки параметров ОССН выполнять вход от имени учётной 
записи администратора изег на уровне целостности «Высокий». 

• Установить все доступные обновления безопасности ОССН с сайта 
Ыір://азігаІіпих.ги/ирдаіе.ЫтІ (при наличии доступа к сети Интернет). 

• Настроить загрузчик на ядро Нагдепед, и убрать из меню все другие варианты загрузки, 
включая режимы восстановления: 

•запустить графическую утилиту «Панель управления», «Система», «Загрузчик ОНЫВ2» в 
вкладке «Основное», «Время ожидания», установить требование автоматической загрузки 
пункта меню «НагсІепесІ» (без режима восстановления): «Немедленно»; 

•отключить поиск дополнительных ОС (включен опцией «Проверка наличия операционных 
систем») и генерацию гесоѵегутоде (включена опцией «Сгенерировать записи для 
восстановления системы»), при этом произойдёт переформирование файла /ЬооІ/дгиЬ/дгиЬ . 
сід; 

•нажать «Применить» и далее для выполнения настроек выполнить редактирование файла 
/Ьооі/дгиЬ/дгиЬ. сід для этого запустить терминал Р/у в «привилегированном» режиме; 
•выполнить создание резервной копии файла /Ьооі/дгиЬ/дгиЬ. сід ; 

•выполнить редактирование файла /Ьооі/дгиЬ/дгиЬ. сід , исключив из него опцию загрузки 
(последний параметр тепиепігу, начиная со строки «тепиепігу . . . депегіс . . . {», до символа 
«}») ядра Оепегіс (тем самым будут удалены лишние варианты загрузки ОССН). 

• Выполнить перезагрузку и дополнительную настройку ВІ05: 

•при использовании архитектур, отличных от /л/е/, установить пароль на загрузчик согласно 
документации; 

•установить единственным устройством для загрузки ОССН — жёсткий диск, на который была 
произведена установка ОССН; 

•при поддержке компьютером соответствующих технологий включить режим загрузки 
зесигеЬооі с использованием ключей учётной записи пользователя компьютера (создать 
ЫЗВ- носитель с помощью азіга-зесигеЬооі, и далее импортировать ключи в ВІОЗ'з, 
соответствии с инструкциями Ыірз://ѵѵікі.азігаІпих.ги/рааез/ѵіеѵѵраае асііоп?рааеІсІ=20217938). 

• Проверить параметры монтирования разделов в файле /еіс/ізіаЬ: 

•раздел /Ьооі рекомендуется монтировать с опциями го (перед обновлением ядра 
смонтировать в л/у), для этого параметр монтирования указанного каталога в файле /еіс/ізіаЬ 
изменить с сіеіаиііз на го; 

•разделы /Ьоте, /ітр, /ѵаг/ітр рекомендуется монтировать с опциями поехес, посіеѵ, позиісі 
для чего параметры монтирования указанных каталогов в файле /еіс/ізіаЬ изменить с сіеіаиііз 
на л/у поехес, посіеѵ, позиісі. 

• Включить блокировку интерпретаторов: 




•при использовании графического интерфейса запустить утилиту 11у-ас!тіп-зтс, открыть 
«Монитор безопасности» и выбрать пункт 5 «Блокировка интерпретаторов», нажать 
«Настроить блокировку интерпретаторов» и далее выбрать «Включить блокировку 
интерпретаторов»; 

•при настройке из терминала Р/у необходимо в «привилегированном» режиме выполнить 
команду просмотра текущих настроек командой зузіетсіі із-епаЫесІ азіга-іпіегргеіегз-Іоск (ес¬ 
ли блокировка не настраивалась, то выводится предупреждения об ее отсутствии азіга- 
іпіегргеіегз-Іоск. зегѵісе) - , для включения выполнить команду азіга-іпіегргеіегз-Іоск епаЫе 
(отключение производится запуском данной команды с параметром СІізаЫе); после настройки 
для проверки повторить команду зузіетсіі із- епаЫесІ азіга-іпіегргеіегз-Іоск: 
гооІ@азІга:/Ііоте/изег# зузіетсіі Із-епаЫесІ азіга-іпіегргеіегз-Іоск епаЫесІ 

• Выполнить настройку блокировки консоли (блокировка надраивается автоматически 
при установке ОССН): 

•запустить графическую утилиту «Политика безопасности» (раздел «Настройки безопасности 
/ Политика консоли и интерпретаторов»); 

• Включить блокировку консоли. 

• Включить блокировку установки бита исполнения: 

•для блокировки только до перезагрузки ОССН выполнить команду ес!ю 1 > 

/\рагзесіз/посіітосіх ; 

•для полной блокировки во всех сессиях ОССН выполнить команду ес!ю 1 > 
/еіс/рагзес/посктосіх (настройка действует только после перезагрузки ОССН) или азіга- 
посктосіх-іоск епаЫе (блокировка действует сразу, в том числе в текущей сессии ОССН); 
•данные настройки доступны в графической утилите «Политика безопасности» (раздел 
«Настройки безопасности / Системные параметры»), 

• Включить блокировку макросов: 

•данная настройка («Макросы / Блокировка макросов») доступна в графической утилите 
«Политика безопасности» (раздел «Настройки безопасности / Системные параметры») и с 
помощью утилиты азіга-тасгоз-Іоск ; 

•в офисном пакете ИЬгеОШсе выбрать меню «Сервис», «Параметры», далее «ИЬгеОШсе», 
«Безопасность», «Безопасность макросов» и выбрать параметр «Очень высокий». 

• Включить блокировку трассировки рІгасе\ 

•в терминале Р/у в «привилегированном» режиме выполнить команду просмотра текущих 
настроек зузіетсіі Із-епаЫесІ азіга- рігасе-іоск (если блокировка не настраивалась, то 
выводится предупреждение об отсутствии азіга-рігасе-іоск. зегѵісе)', 

•для включения выполнить команду азіга-рігасе-іоск епаЫе (отключение производится 
запуском данной команды с параметром СІізаЫе)', 



•после настройки для проверки повторить команду зузіетсіі із-епаЫед азіга-рігасе-Іоск 
гооІ@а5Іга:/Ііоте/изег# зузіетсіі із-епаЫесІ азіга-рігасе-Іоск епаЫесІ 

• Включить контроль цифровой подписи ЕІР-файлов (исполняемых файлов): 
•установить в файле /еіс/дідзід/дідзід_іпіігатіз. сопі значение параметра 0Ю8Ю_ЕІ-Е_МСЮЕ 
- 1 ; 


•выполнить перемонтирование каталога ІЬооІ с доступом на чтение и запись командой тоипі 
-о гетоипі,т /Ьооі\ 

•выполнить команду ирдаіе-іпіігатіз -и -к аН\л перезагрузить ОССН. 

• Включить гарантированное удаление файлов и папок: 

•в файле /еіс/ізіаЬ добавить параметр зессІеІ=х (где х определяет число стираний 
фиксированными последовательностями вида «11111111», «01010101», «10101010», 
«00000000») или зесдеігпд (стирание псевдослучайной последовательностью) к параметрам 
монтирования разделов (например для каталога /Моте). 

• Включить межсетевой экран иіѵѵ (графическая утилита диіѵѵ): 


* Епсі оі і'Пе 

* Ьагсі І'гіге 50000000 

* 50« Г5І2Ѳ 25О00000 

* Ьагсі поІЧІе 4096 
« зоіі поШе 2048 

* ііагсі пргос 2000 
^ 50 ІІ Пргос 1000 

ѵ. ГПГР П 


•в меню «Панель управления», «Прочее», «Настройка межсетевого экрана» выбрать 
необходимый профиль и изменить статус на «Включено»; 

•при необходимости задания уровня журналирования выбрать его в меню «Правка», 
«Параметры»; 

•настроить межсетевой экран (модуль ядра МеіЕІІіег с использованием консольной команды 
іріаЫез) в минимально необходимой конфигурации (т. е. настроить режим, когда по 
умолчанию все запрещено, кроме необходимых исключений, для чего могут также 
использоваться команды ІріаЫез, иіѵѵ). 

• Включить системные ограничения иіітііз: 

•установить в файле /еіс/зесигііу/Іітіі. зсопі параметры системных ограничений: * Магд соге 0, 
* Магд ізіге 50000000, * Магд пргос 1000; 

•из терминала ЕІу в привилегированном режиме выполнить команду просмотра текущих 
настроек зузіетсіі із-епаЫед азіга- иіітііз- сопігоі (если блокировка не настраивалась, то 
выводится предупреждение об отсутствии азіга-иіітііз-сопігоі-зегѵісе); 



•для включения выполнить команду азіга-иіітііз-сопігоі епаЫе (отключение производится 
запуском данной команды с параметром сіізаЫе); 

•после настройки для проверки повторить команду зузіетсіі із-епаЫесі азіга-иіітііз-сопігоі: 

• Включить режим киоска для непривилегированных учётных записей пользователей 
(пользователей с уровнем целостности «Низкий»), для чего использовать графическую 
утилиту ііу-адтт- кіозк (порядок включения режима киоска для учётной записи поль¬ 
зователя описан в документации «Руководство по КСЗ. Часть 1»), 

• Включить графический киоск Р/у с помощью графической утилиты ііу-асітіп-зтс 
(порядок включения режима графического киоска для учётной записи пользователя 
описан в документации «Руководство по КСЗ. Часть 1»), 

• Включить контроль подписей (в настройках модуля сіідзід: ОЮ5КЗ_ХАТТВ_МООЕ=1) в 
расширенных атрибутах ( хаііг ), для чего сгенерировать ключи и подписать цифровой 
подписью в хаііг все основные файлы ОССН (рекомендуемые каталоги для подписи: /ЧЬ, 
ПІЬ64, /НЬ32, /Ып, /зЫп, /Ьооі, /орі, /згѵ, /изг). 

• При использовании мандатного управления доступом и обработке файлов с уровнем 
конфиденциальности выше минимального настроить дополнительное защитное 
преобразование файлов (с использованием команды дрд или встроенных функций 
файлового менеджера ііу-іпі): 

•открыть в файловом менеджере ііу-іт каталог «Документы» и с использованием 
контекстного меню создать файл «Документ ИЬге Оііісе»; 

•с использованием контекстного меню файла «Документ ИЬге- Оііісе. осіі» выбрать пункт 
меню «Действия», «Защитное кодирующее преобразование», ввести 2 раза пароль; в 
результате будет создан файл «Документ ИЬгеОШсе. осіі. дрд», теперь данный файл может 
быть «открыт» (при этом будет восстановлен исходный файл), либо выполнено «Защитное 
раскодирующее преобразование» (при этом после восстановления файл «Документ 
иЬгеОііісе. осіі. дрд» будет удалён) с использованием ввода пароля. 

22. Для работы с конфиденциальной информацией в сети настроить защитное 
преобразование пакетов с помощью создания доверенной сети ѴРЛ/: 

•осуществить настройку ѴРЛ/ соединения в меню сетевого подключения (по нажатию левой 
кнопки мыши на значке сети) с помощью меню «Соединения ѴР№, «Добавить \/РЛ/соедине¬ 
ние. . . »; 

•выбрать соединение ОрепѴРМ установить параметры соединения в соответствии с 
параметрами сервера ѴРЛ/, к которому осуществляется подключение; 

•в вкладке « ѴР№ для установки соединения ввести адрес сервера ѴРЫ в поле «Шлюз», 
указать соответствующий тип аутентификации на сервере в поле «Тип» и задать параметры 
подключения, соответствующие данному типу; 



•дополнительные параметры (такие, как сжатие, используемые алгоритмы шифрования, 
протокол и пр. ) задать после нажатия кнопки «Дополнительно. . . » в вкладке «ѴР№ в 
соответствии с настройками VРN; 

•задать параметры получения адреса сети \/РЛ/ в вкладках «Параметры ІРѵ4» или 
«Параметры ІРѵб»: 



23. Настроить обработку конфиденциальной информации при обмене почтовыми сообщения, 
используя защитные ѲРО-преобразования писем с помощью плагина для почтового 
приложения ТбипдегЫгсІ ЕпідтаіІ, для чего при создании каждого сообщения электронной 
почты использовать быструю кнопку доступа «Защита» и выбирать «Шифровать это 
сообщение» и/или «Подписывать это сообщение». 

• При создании новых учётных записей пользователей формировать пароли с заданным 
уровнем сложности в соответствии с политикой безопасности, для чего использовать 
графическую утилиту «Политика безопасности». 

• Настроить рат_іаІІу для задания необходимых параметров блокировки учётных 
записей пользователей (при попытках подбора паролей) с использованием графической 
утилиты «Политика безопасности» задать параметры количества «Неуспешных 
попыток» (например, 2 попытки), а также периода блокировки и разблокировки 
(например, 60 секунд). 

• Настроить дисковые квоты в ОССН (для этого требуется установленный пакет диоіа): 
•в файле ІеІс/ізіаЬ добавить соответствующие опции монтирования (например, изгдиоіа — 
включения квот для пользователей, дгрдиоіа — для включения квот для групп); 

•выполнить перемонтирование изменённых файловых систем командой тоипі -о гетоипі 
точка_монтирования; 

•для создания квот (индексных файлов, которые описывают сами квоты) использовать 
команду диоіасбеск -Ісдит /боте; 




•отредактировать квоты заданного пользователя, например, для учетной записи 
пользователя Недовыполнить команду ес/деоНа— и Іезім выполнить редактирования настроек 
квот в редакторе (редактор по умолчанию папо, который может быть изменён командой 
ирсіаіе-аііегпаііѵез-сопіід ей Ног), затем сохранить изменения. 

• Отключить все неиспользуемые сервисы (в том числе сетевые), которые запускаются 
при старте ОССН командой зузіетсі- депіе. 

• Настроить параметры ядра ОССН в файле /еіс/зузсіі. сопі. 

•настроить дополнительные параметры ядра: /д. зиісІ-сІитраЫе = 0, кегпеі. 

гапс!отіхе_ѵа_зрасе = 2, пеі. ірѵ4. ір_Іогѵ/агсІ = 0, пеі. ірѵ4. сопі. аІІ. зепсІ_гесІігесІз = 0, пеі. ірѵ4. 
сопі. сіеіаиіі. зепсІ_ гесіігесіз = 0; 

•перегрузить ОССН (данные параметры будут автоматически применены после перезагрузки 
ОССН). 

• Заблокировать исполнение модулей руікоп с расширенным функционалом: 
•выполнить команду «НпсІ/изг/НЬ/руНюп* -Іуре I -пате "_сІуре*" -ехес зисіо фкд-зіаіоѵеггісіе- 
ирсіаіе-асісі гооі гооі 640 |}\;» (для удаления можно применять аналогичную команду, заменив 
«-ирсіаіе -аМ гооі гооі 640» на «--гетоѵе»); 

•проверить изменения (установку владельца гооі.тооі и прав доступа 640 «п/ѵ,г,-») командой 
ІіпсІ/изг/ІіЬ/руІІюп* -Іуре I -пате "_сІуре*" / хагдз Із -/. 

• Запретить непривилегированным учётным записям пользователей (с уровнем 
целостности «Низкий») подключение сменных устройств (носителей), к которым 
потенциально может быть осуществлён несанкционированный доступ, для чего с 
использованием графической утилиты «Политика безопасности» не включать такие 
учётные записи пользователей в группу ііорру (данная настройка в ОССН действует по 
умолчанию). 

• Настроить систему аудита на сохранение файлов журналов {Іод- файлов) на удалённой 
машине. Для этого применить централизованное протоколирование с использованием 
системы ІаЬЫх (подробно порядок действий описан в документации «Руководство 
администратора. Часть 1»), 

• Установить мандатный контроль целостности на всех основных файлах и каталогах 
корневой файловой системы ОССН: 

•в графической утилите ііу-асітіп-зтс «Политика безопасности», «Мандатный контроль 
целостности», «Целостность файловой системы» нажать кнопку «Установить» для 
изменения мандатного уровня целостности объектов файловой системы в соответствии с 
заданным фильтром (данное действие можно выполнить с использованием команды зеМз- 



•установку мандатного контроля целостности следует проводить после всех настроек 
безопасности, так как дальнейшее администрирование возможно только войдя под высоким 
уровнем целостности, или после снятия мандатного контроля целостности с файловой 
системы командой ипзеі-із-ііеѵ. 

Содержание отчёта о выполненной работе 
В отчёте о выполненной работе необходимо указать: 

• Полный перечень использованных команд с кратким описанием их назначения. 

• Примеры выполнения команд, которые были использованы в ходе работы с описанием 
результатов их выполнения. 

• Описание порядка работы с графической утилитой «Политика безопасности» (ііу- 
асітіп-зтс) при осуществлении настройки необходимых параметров защищённого 
режима работы ОССН. 

4. Список и назначение используемых утилит, необходимых в ходе настройки защищённого 
режима работы ОССН в соответствии с Азіга Ипих ВесІ-Воок. 

Контрольные вопросы 

• Каковы особенности установки ОССН для её дальнейшей работы в защищённом 
режиме в соответствии с Азіга Ипих ВесІ-Воок? 

• Какие необходимо выполнить блокировки для работы ОССН в защищённом режиме в 
соответствии с Азіга Ипих ВесІ-Воок? 

• Для чего для «непривилегированных» учётных записей пользователей 
осуществляется блокировка интерпретаторов, терминалов и установки бита ис¬ 
полнения? 

•Какие специальные настройки монтирования файловой системы необходимо 
использовать в файле / еіс/ізіаЬ ? 

• Что в ОССН подразумевается под «защитным преобразованием»? 

• Какие подсистемы используют защитные преобразования? 

• Как можно настроить параметры блокировки учётной записи пользователя? 

• Какие средства настройки межсетевого экранирования доступны в ОССН? 
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Пожалуйста, после скачивания не удаляйте этот текст, так мы можем 
взаимодействовать для дальнейшей редакции этого учебного пособия. 
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